Re: nptl 0.26

["dada1" <dada1 cosmosbay com>]

>
> > I do think the same optim can be done in pthread_cond_signal() and
> > pthread_cond_broadcast().
>
> pthread_cond_signal() must be called with the lock held since we wake
> exactly one thread waiting on the futex and this must be one which can
> actually receive the signal.  If the lock wouldn't be held this might
> not be the case.

No Ulrich. I dont agree. Sorry if I bother you.

This is all the magic/complexity of futex interface.

There is no semantic difference between

******** your version)

lll_lock()
if (condition) {
  ++sequence;
  futex_wake(&sequence, 1);
  }
lll_unlock()

****** The alternate version more lock friendly)

lll_lock()
if (condition) {
  ++sequence;
  lll_unlock(); /* release the lock before the syscall */
  futex_wake(&sequence, 1);
  }
else
   lll_unlock();

Why should the wakeup thread should lock something that the waiter cant lock
(as the lock must be released before calling futex_wait())
The futex syscall doesnt need locks to work.

The thread willing to block will block if and only if sequence didnt change.
Only the evaluation/change of the sequence should be protected by the lock


>
> pthread_cond_broadcast() actually can drop the lock early since all
> waiters are woken.

yes

>
>
> > By the way, why are you using 64 bits sequence number ? They can be 32
bits
> > if comparisons are carefully done.
>
> There is no careful or not in a plain comparison of larger or not.  And
> this is required.

Could you be kind enough to give a pointer to a documentation that will
enlighten me ?
Using 32bits could give us lockfree signal/broadcast functions on i486+.

>
>
> > sys_futex() uses 32 bits integer, and it is *impossible* to think 2^31
> > threads could be used in a threaded application on ia32 ...
>
> That's unrelated.  The 64 bit values are no counters but sequence
> values.  And they have to be strictly monotonic.

Thanks

Eric