This is the mail archive of the
pthreads-win32@sources.redhat.com
mailing list for the pthreas-win32 project.
Re: New pthread_once implementation
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