Re: next round: glib thread safety proposal

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi, Owen

> >
> > I do not know, if the above condition wait scenario would apply to this
> > too, so it might or might not apply to glib main loop. You'll know best.
> 
> It definitly doesn't apply to timeouts added with g_timeout_add(),
> since they can never be called prematurely. The scheduling of
> GSource's is some what analogous to the timed mutex waits,
> but since the absolute current time is passed to the source before
> each poll(), a source will have no trouble figuring out how
> much longer it needs to wait.

Ah, yes I thought this would happen. Anyway, as you are adding such an
absolute time (or did I get that wrong?), I'll use it then for this
purpose too.

> > no, the cache coherence protocol to be found on all such systems is
> > supposed to prevent this. I asked someone from our institute with
> > detailed knowlege in this topic and he said, that we could rely on such
> > not happen.
> 
> There was a long thread on comp.programming.threads about
> this some months ago:
> 
>  http://www.dejanews.com/dnquery.xp?search=thread&recnum=%3c1998\
>  May28.082712@bose.com%3e%231/1&svcclass=dnserver
> 
> Now, this is wisdom from Usenet (pearls from swine, so to
> speak), and I don't put a whole lot of faith in it. But the
> general conclusion of that thread seems to be that on some
> MP architectures, the approach may not be safe.
> 
> Re-reading the thread, I see, that the problem is a little
> different than I presented it above. Essentially, it is:
> 
>  1) Thread B reads in some other data, which happens to
>     be in the same cache line as the contents of the mutex.
> 
>  2) Thread A writes the contents of the mutex and the
>     pointer to the mutex.
> 
>  3) Thread B reads in the pointer to the mutex, and uses
>     it to access the stale cache data for the contents
>     of the mutex.
> 
> This is possible for memory models that allow out-of-order
> reads.

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. 

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

> > - what about the seperation of mutex and cond function into two classes,
> > as
> >   Aaron suggested. I do personally not think, that this would help, as
> > there
> >   is only one instance of that class anyway, and the user is actually
> > not
> >   supposed to touch this in normal operation. It's just for some special
> >   cases (named mozilla ;-).
> 
> My opinion is that it isn't necessary. We can still extend both
> the mutex and the condvar interfaces, with a single vfunc block -
> they'll just end up a bit mixed together. (And we can't extend
> the block without breaking compatibility in any case)

yes, I agree.

> > - what about the GAbsTime, or whatever you name it for your purpose, can
> >   they be uses 'by value'. It would make programming much more simple 
> > and
> >   only very slightly slower.
> 
> This is a style issue, and I don't have much of an opinion
> on it. I think passing and returning structures (of any size)
> by value is portable, though I don't know about the
> performance implications. If I was desigining the interfaces,
> 
> I'd probably tend to pass by reference, but mostly because
> structures aren't passed by value anywhere in GLIB or
> GTK+ currently.

ok, we'll do it that way.

As for the patch, that I'll post to
ftp://ftp.gtk.org/incoming/glib-wilhelmi-981130-0.patch.*

Here's the README:

Hi, 

This patch consists of two files glib-wilhelmi-981130-0.patch.gz and
glib-wilhelmi-981130-0.patch.tar.gz, that should be both applied/unpacked
to the CVS glib.

this patch aims for laying the grounding for making glib thread-safe.
Please see the thread: "next round: glib thread safety proposal" on
gtk-devel-list for rationals and the like. 

Contained is:
  - implementations for mutexes and conditions. They can be adjusted at
    run-time by calling g_thread_init()
  - implemenations of static mutexes, that can be initialized statically.
  - 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)
  - 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
the
    resp. file for approval.)

So, this patch actually is only to get it to Owen. So he'll handle this.

(So, whoever is reading this, don't just apply.. :-)

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