Re: GObject thread safety

[Tim Janik <timj gtk org>]

On Thu, 1 Nov 2001, Alex Larsson wrote:

> On Fri, 2 Nov 2001, Tim Janik wrote:

> > right, a single object can only be used in one thread at a time.
> > that's the reason we have a gdk/gtk wide global lock. you need to aquire it
> > before you access any gdk/gtk objects.
> > the same holds for other objects people are using, say you derive a bunch
> > of objects from GObject to implement your model, then you need to make sure
> > to have and hold a model lock before you access any of those.
> > 
> > > 	Is it then the case that only the type system is thread safe ?
> > 
> > GObject isn't thread-unsafe, it just uses the normal glib locking convention,
> > of the user having to pay attention to lock hist structs before using them.
> > that can't be done for the type system of course, so we do fine grained locking
> > there.
> 
> Otoh, we could add some atomic ops to implement refcounting that is MT 
> safe without having the overhead of locking. I've did this for the 
> ref/unref in the Mozilla javascript engine, and it makes quite a 
> difference (compared to locks).
> 
> I do think many people will assume that g_object_ref/unref() can be used 
> between threads...

i'd really say then they make the wrong assumptions and didn't get how
to do threaded programming in glib. what point is there in just reffing
objects in threads? at some point they're going to use it and then they
need some global object-entity lock anyways.

as for the performance hit, the worst thing about a mutex is the "lock"
directive (or memory barriers on non-x86 archs) which nukes your cache
lines. you should hear alan rant about that ;)
and as reference counting is extensively used in the signal system, i'm
very much against nuking cache lines upon every handler being invoked.

as for the atomic int implementation, i have to say two things (besides
being too late for 2.0 as havoc pointed out already):
- all those get/set/add/init/whatnot functions should really be avoided
  in favour of one cross-platform compare_exchange implementation.
- falling back to static mutexes for non-x86 is really not acceptable,
  because a) static mutexes are amongst glib's worst locking scenarios
  as they require an extra global lock with possibly high contention
  (think one global lock for all static mutexes in a program), and
  b) we shouldn't write x86-specific code in the sense that we "work"
  everywhere, but only sufficiently speedy on x86.
and before you say "we should simply provide asm statements for other
platforms as well", read up on the complexity on that topic, e.g.
  http://gcc.gnu.org/ml/java/2001-01/msg00079.html
is an email from ulrich drepper which gives a pretty good outline
on why a) you need to use functions and can't go with macros, and
b) real portability is probably too complex for what we'd want to put
into glib.
  

> 
> / Alex
> 

Tim - awaiting the flames - Janik

---
ciaoTJ