Re: next round: glib thread safety proposal

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi, Owen

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

So, did I get it right: We will use the default implementation for
GStaticMutex, no matter what the user supplies in g_thread_init(), but
provide a fallback for systems without a default implementation, that
implements GStaticMutex by means of GMutex, as supplied with
g_thread_init()?

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

Yes, that could be done without problem, but if we have a system with
default thread system, GStaticMutex will most certainly be the fastest
way, faster than anything the user might set with g_thread_init. (Think of
the NSPR implementation.) So it might for the majority of systems be best
to use GStaticMutexes, because they have a default implementation.

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

Agreed, first we have to get that change in, and for 1.3 other things
might follow.

Bye,
Sebastian
-- 
+--------------============####################============--------------+
| Sebastian Wilhelmi, Institute for Computer Design and Fault Tolerance, |
| University of Karlsruhe;  Building 20.20, Room 263,  D-76128 Karlsruhe |
| mail: wilhelmi@ira.uka.de;  fax: +49 721 370455;  fon: +49 721 6084353 |
+-----------------> http://goethe.ira.uka.de/~wilhelmi <-----------------+