Re: next round: glib thread safety proposal

[Owen Taylor <otaylor redhat com>]

> > > 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. 
 
> > We could also do without static mutex altogether for the
> > purposes of GLIB. We could just make all the mutex global
> > and initialize them in something called from
> > g_thread_init. Yes, that's a bit ugly.
> 
> no, thats not nice, imagine you'll write a library, that you want to make
> thread safe, you would have to make an init call to it for allocating the
> mutexes and then you will have problems of order, imagine, that you first
> allocate the mutexes and then the main-program calls g_thread_init. thats
> not good. having a chain (i.e. the library init function calls
> g_thread_init) is not good either, as you could be using two libraries and
> g_thread_init must be called excactly once (or never, of course for single
> threaded programs) 

Well, if every program does g_thread_init() first, then
synchronization facilities can be provided so that other libraries
can safely initialize themeselves in any order. For instance,
cached monitors. 

my_library_init ()
{
  static gboolean initialized = FALSE;

  g_monitor_cached_enter (&initialized);
  if (!initialized)
    {
      [...]
      initialized = TRUE;
    }
  g_monitor_cached_leave (&initialized);  
}

But I don't disagree that static mutexes are useful, and I
think your current implementation of them should be OK-ish.
(Though it is a fairly big performance hit for any system
providing their own thread funcs; there would be some
argument for preallocating the most crucial locks - like
those in GList)

> etc. etc. static mutexes are a MUST, I think. BTW, what
> about the name StaticMutex, does it sound properly for a native speaker???

Sounds fine to my ear.
 
> > >   - convenience macros for using static mutexes, for the usage look at
> > >     garray.c (Owen: they are of course only syntactic sugar, but nice to
> > >     use, what do you think)
> > 
> > The g_lock() stuff? Well, something like g_lock_define which
> > doesn't have the semantics of a function call should definitely
> > be all uppercase. Other than that
> 
> Ah, I'll change that.
> 
> (I simply assume that 'Other than that' was meant to be continued by 'it
> is extraordinary great' ;-)

Something along those lines ;-)
  
> > >   - a whole lot of configure stuff to get things right.
> > >   - a first shot at making glib threadsafe. I made the files garray.c,
> > >     gcache.c, gdataset.c, ghash.c and glist.c reentrant. (Owen: does 
> > >     that
> > >     look sane???, If mutexes are in glib, I'll look at making all files
> > >     reentrant, but will not commit until I asked the main maintainer of
> > 
> > Yeah, this looks pretty much OK. The list stuff is where the
> > locks are going to really hurt performance, but doing
> > better would probably mean using per-thread free lists.
> 
> Ah, this brings us to the point, you so far avoided to comment on: what
> about thread specific data? It would be nice to have (even though, to be
> honest, it is most certainly not much faster than mutexes).

My vague memory of timing it was that get_thread_specific was
somewhere from 40% - 70% of the time of a mutex lock/unlock
pair, depending on the particular type of mutex. 

I don't think we need to add thread specific functions to GLIB for the
purposes of making if other people using the gthread API need
it. Personally, I think we should probably leave them out for right
now.

Regards,
                                        Owen