Re: New pthread_once implementation

[Ross Johnson <rpj@callisto.canberra.edu.au>]

On Tue, 2005-05-31 at 12:28 -0400, Gottlob Frege wrote:
> I think that might be reasonable.
> 
> Here's another tact we could try:
> 
> In the case of cancel, release the semaphore BUT do NOT reset the
> control state.  In the waiting case, after waiting, check if state ==
> done.  If not done, we know something went wrong - fall back to using
> a named mutex.  Note that ALL new threads coming in will go to the
> wait case then into the namedmutex code - after a cancel, no threads
> try to call init in the normal way.
> 
> Does that make sense?

The cancellation handler must change 'state' before checking for the
semaphore, otherwise there's no possibility of managing the race between
the cancelled thread and a thread that has just entered the wait track
but not yet created the semaphore. That waiter will be stranded until a
new thread comes by.

The form of pthread_once with the MCS queue-based lock is the same as
that proposed by Alexander. Vlad's MCS lock implementation is the
missing element: it is light-weight in the uncontended case; is
efficient otherwise (including attempting to minimise cache-coherence
operations on MP systems), and; can be incorporated without changing the
library's ABI. I think it deserves inclusion in the next release.

If there are refinements that can be made to pthread_once later then
they can be considered, but in the meantime we will have a fully
working, robust, and efficient pthread_once.

Ross