This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pthread_cond_wait


If your are new to futexes, you should also read this:
http://people.redhat.com/drepper/futex.pdf
Without the understanding of futexes, you cannot understand the glibc
part of cond_wait and mutexes.

After, look into the original code of pthread_cond_*, and you find a tricky
combination of loops and variables (wakeup_seq, total_seq ...) which
guaranty that no signal is lost.

Gilles.

Polina Dudnik wrote:
Hi,

Thank you for the reply. I have made an attempt at implementing a mutex-less pthread_cond_wait and pthread_cond_signal.

Specifically I am using futexes to implement it (below).

I define a global integer initialized to zero, which is my futex.

So, my cond_wait function looks like this:

int rn = lll_futex_wait(&event, event);

cond_wait looks like this:

GetLock(&lock, threadid+1);
event++;
ReleaseLock(&lock);
lll_futex_wake(&event, INT_MAX);

And cond_broadcast looks like this:

GetLock(&lock, threadid+1);
event++;
ReleaseLock(&lock);
lll_futex_wake(&event, 1);


However, I am still loosing signals and I don't know why. If anybody is strong with futexes, I would really appreciate any information. Thanks.






#define lll_futex_wait(futex, val) \
  ({                                          \
    register const struct timespec *__to __asm ("r10") = NULL;           \
    int __status;                                  \
    register __typeof (val) _val __asm ("edx") = (val);                  \
    __asm __volatile ("syscall"                              \
              : "=a" (__status)                          \
              : "0" (SYS_futex), "D" (futex),                  \
            "S" (FUTEX_WAIT),                         \
            "d" (_val), "r" (__to)                      \
              : "memory", "cc", "r11", "cx");                  \
    __status;                                      \
  })


#define lll_futex_wake(futex, nr) \ do { \ int __ignore; \ register __typeof (nr) _nr __asm ("edx") = (nr); \ __asm __volatile ("syscall" \ : "=a" (__ignore) \ : "0" (SYS_futex), "D" (futex), \ "S" (FUTEX_WAKE), \ "d" (_nr) \ : "memory", "cc", "r10", "r11", "cx"); \ } while (0)



Gilles Carry wrote:

Polina Dudnik wrote:

Hi,

I would like to write my own version of pthread_cond_wait, which doesn't have a mutex as one of it's parameters, to be used with transactional memory model. I am not sure why it is important to have the mutex locked before calling lll_lock (cond->__data.__lock, pshared). What would happen if the mutex was unlocked before calling lll_lock (cond->__data.__lock, pshared). Thanks.


Hi,
As far as I remember, the external mutex is to avoid loss of signals.
Releasing the external mutex before the internal one would let a time window
in which a signal could be issued before the waiter is put into the waiting queue.
Anyway, before modifying pthread_cond_* stuff, you should carefully read this:
http://www.opengroup.org/onlinepubs/009695399/functions/pthread_cond_wait.html


and especially "Features of Mutexes and Condition Variables".

Hope this helps.

Gilles.





-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Gilles.Carry Linux Project team mailto: gilles.carry@bull.net Phone: +33 (0)4 76 29 74 27 Addr.: BULL S.A. 1 rue de Provence, B.P. 208 38432 Echirolles Cedex http://www.bull.com http://www.bullopensource.org/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]