Re: next round: glib thread safety proposal

[Jeff Garzik <jgarzik pobox com>]

Owen Taylor wrote:
> 
> 
> > > > But: It is highly desirable to have those StaticMutex'es and to have 
> > > > them
> > > > as fast as possible (because they will most likely be used for glib's
> > > > internal locking, see below).
> > > > So I changed the things to actually use the
> > > > default implementations mutexes statically, and fall back to the 'lock
> > > > everytime and check for existence' method, if a nondefault 
> > > > GMutexFunctions
> > > > is passed to g_thread_init(). (Look at the code in glib.h and the
> > > > generated glibconfig.h, as I can't describe it better.)
> > > 
> > > I don't quite understand what your code does - you have:
> > > 
> > > typedef struct _GStaticMutex GStaticMutex;
> > > struct _GStaticMutex
> > > {
> > >   $g_mutex_default_type default_mutex;
> > >   struct _GMutex* runtime_mutex;
> > > };
> > > 
> > > Why do we need two mutexes?
> > 
> > I thought, that we should switch our internal locking mechanism, if so
> > desired by g_thread_init()? If not, we can of course stick to the default
> > implementaion with the fallback, as already provided. My solution will
> > however use the provided mutexes. I do not know any situation, where the
> > default mutexes arn't good enough to achive glib thread safetey, so I
> > would really welcome to just leave out the 'runtime_mutex'
> 
> No, I don't want to do that. We can't assume we'll have default
> mutexes at all on a platform that wants to use the user provided
> thread funcs. 

What do you think about using asm spinlocks on uniprocess platforms?

SMP-safe should be the default, but since the majority of the machines
out there are still UP (IMHO), glib should include an option to use faster
spinlocks if desired.

	Jeff