This is the mail archive of the libc-alpha@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: [RFC] [BZ 14417] Document condvar synchronization


On Wed, 26 Sep 2012 18:35:13 +0200, Torvald wrote:
> > If Austin group says that the glibc behavior is not kosher, we can
> > always drop all traces of __woken_seq and live with spurious
> > wakeups, but I hope we don't need to do that.
> 
> If we go that route, we can probably drop most of the counters and
> just depend on the futex queues (which respect happens-before).

Not really.  I think it might just be possible to use the futex value
as a proper counter to decide on order.  If the signaller increments
the futex value on entry and the waiter decrements the value in W3, you
should get proper order.  Here's what I'm thinking:

* Waiter gets the current futex value in W1
* Signaller increments futex in S1 and calls wake
* Waiters race for the cond_lock and the first one in gets to compare
  its futex value with the current futex value.  The winner proceeds to
  W3 only if its value is less than the current futex value.  Otherwise
  it goes into W2 and back to FW.
* When in W3, the waiter decrements the futex value.

This seems to eliminate all of the counters, so I think I may be
missing something.  I'll try to set up a more complete theory based on
this tomorrow, hopefully with some working code.

Regards,
Siddhesh


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