[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: nptl 0.26



> But it cannot be generally done.  For pthread_cond_signal and
> pthread_cond_broadcast, for instance, the lock must be held until after
> the notification.  I was going to look at all these cases when the time
> comes (i.e., I have some time).  You beat me on this and I think rwlocks
> are indeed fine.  I've made some changes now and they'll be in the next
> source drop.

I dont understand what you mean. We may not speak of the same lock.

I do think the same optim can be done in pthread_cond_signal() and
pthread_cond_broadcast().
The internal cond lock can and should be released before the futex_wake().

By the way, why are you using 64 bits sequence number ? They can be 32 bits
if comparisons are carefully done.

sys_futex() uses 32 bits integer, and it is *impossible* to think 2^31
threads could be used in a threaded application on ia32 ...

cond_signal(cv)
{
   lll_lock(cv->lock);
   if (cv->total_seq - cv->wakeup_seq > 0) {
     ++cv->wakeup_seq;
+     lll_unlock(cv->lock);
     futex_wake(&cv->wakeup_seq, 1);
 +    return;
   }

   lll_unlock(cv->lock);
}

cond_broadcast(cv)
{
   lll_lock(cv->lock);

   if (cv->total_seq - cv->wakeup_seq > 0) {
     cv->wakeup_seq = cv->total_seq;
+     lll_unlock(cv->lock);
     futex_wake(&cv->wakeup_seq, ALL);
+     return;
   }

   lll_unlock(cv->lock);
}



Eric





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]