This is the mail archive of the
pthreads-win32@sources.redhat.com
mailing list for the pthreas-win32 project.
Re: New pthread_once implementation
- From: Gottlob Frege <gottlobfrege at gmail dot com>
- To: Vladimir Kliatchko <vladimir at kliatchko dot com>
- Cc: pthreads-win32 at sources dot redhat dot com
- Date: Tue, 31 May 2005 12:28:14 -0400
- Subject: Re: New pthread_once implementation
- References: <1117446923.7427.5.camel@desk.home> <0IHB00BP81S8NK@mta5.srv.hcvlny.cv.net>
- Reply-to: Gottlob Frege <gottlobfrege at gmail dot com>
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?