Re: next round: glib thread safety proposal

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi, Owen

> > ok, I read the thread and if I got it right, it basically said, there
> > might be SMP platforms without hardware cache coherence, that might fail
> > to work correct for the above. (but nobody actually  named such, apart
> > from virtual shared mem systems). So I made it lock the mutex everytime.
> 
> Yeah, I don't know how much of a real problem this is.
> Reading through the Intel hardware specs for MP machines,
> it looks like it can't happen there. (Assumming the processor,
> as opposed to the cache, never makes speculative reads for
> "random" bits of memory)

Anyway, it surly is better to be on the safe side, even if it in our case
forces us to include pthread.h into glib.h. A possible cure is of course
the split of the glib files.

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

> 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) etc. etc. static mutexes are a MUST, I think. BTW, what
about the name StaticMutex, does it sound properly for a native speaker???
 
> >   - 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' ;-)
 
> >   - 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).

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