Re: starvation in pthread_once?

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

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.
> > 
> >
>