This is the mail archive of the
pthreads-win32@sources.redhat.com
mailing list for the pthreas-win32 project.
Re: starvation in pthread_once?
On Tue, 2005-03-08 at 11:11 -0500, Gottlob Frege wrote:
> Do you think it is worth avoiding the named_mutex in favor of a event
> only created on contention (my version)? (I do, obviously).
>
I agree.
Win32 mutexes are VERY slow, even for uncontended lock operations - that
is, about 50 times slower than a CriticalSection. I would guess that a
named mutex is even slower again. A CS is about the same speed as an
interlocked operation if it doesn't block.
I also think that generating the [guaranteed unique] name is a
complication that should be avoided if possible.
News:
I've dropped a new version of pthread_once into CVS (bumping the
library's version from 1 to 2, and dll's name to indicate an ABI
change). It's based on the code that Gottlob posted earlier:-
http://sources.redhat.com/ml/pthreads-win32/2005/msg00029.html
This code works fine without cancellation, but with it included, the
design's efficiency had to be downgraded a little. Threads waiting on a
cancelled initter thread must be woken to compete again to run the
init_routine. I couldn't find any way to manage the repeated
creation/reuse/closure of the event properly without a global CS, but at
least these sections are very short where it matters most.
See:-
http://sources.redhat.com/cgi-bin/cvsweb.cgi/pthreads/pthread_once.c?
rev=1.10&content-type=text/x-cvsweb-markup&cvsroot=pthreads-win32
Crucially, the event is still a per once_control object that is released
on successful return from pthread_once.
I plan on releasing one more pthread*1.dll snapshot to include
init_routine cancellability based on the global cond+mutex used in the
last snapshot, then a pthread*2.dll snapshot using the above code. (DLL
names change only when their ABI compatibility is affected).
Thanks.
Ross
> I'm guessing that for typical usage, contention will be low. And, in
> my own code, I'm considering making statically initialized mutexes (or
> CSes) by using a call_once in their constructor. It would just seem
> like overkill if all my mutexes needed a mutex to init themselves.
>
>
> On Tue, 8 Mar 2005 10:58:23 +0100, Alexander Terekhov
> <TEREKHOV@de.ibm.com> wrote:
> >
> > Grrr. Bad day.
> >
> > if (!once_control) {
> > named_mutex::guard guard(&once_control2);
> > if (!once_control2) {
> > <init>
> > once_control2 = true;
> > }
> > once_control = true;
> > }
> >
> > regards,
> > alexander.
> >
> > Alexander Terekhov/Germany/IBM@IBMDE@sources.redhat.com on 03/08/2005
> > 10:55:53 AM
> >
> > Sent by: pthreads-win32-owner@sources.redhat.com
> >
> > To: Ross Johnson <rpj@callisto.canberra.edu.au>
> > cc: Pthreads-Win32 list <pthreads-win32@sources.redhat.com>
> > Subject: Re: starvation in pthread_once?
> >
> >
> > > DCSI-TLS: (__declspec(thread) for control variable; DLL issues
> > > aside for a moment)
> > >
> > > if (!once_control) {
> > > named_mutex::guard guard(&once_control);
> > > if (!once_control) {
> > > <init>
> > > once_control = true;
> > > }
> > > }
> >
> > Sorry, I meant:
> >
> > if (!once_control) {
> > named_mutex::guard guard(&once_control);
> > if (!once_control2) {
> > <init>
> > once_control2 = true;
> > }
> > once_control = true;
> > }
> >
> > where once_control2 is a non-TLS flag.
> >
> > regards,
> > alexander.
> >
> >
>