pthread_cond_wait

Gilles Carry Gilles.Carry@bull.net
Fri Jul 18 07:20:00 GMT 2008


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/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



More information about the Libc-help mailing list