New pthread_once implementation

[Gottlob Frege]

On 5/30/05, Vladimir Kliatchko <vladimir@kliatchko.com> wrote:
> 
> Regaring MCS version:
> It can be quite expensing, but only when multiple threads call pthread_once
> simultaneously. Also, the overhead is proportional to the number of threads
> so that:
> 1 thread - no overhead
> 2 simultaneous threads - the same overhead as in semaphore based version
> 3 or more simultaneous threads - higher overhead - but is this an important
> case?
> 

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?