Re: instance-private-data issue

[Owen Taylor <otaylor redhat com>]

On Wed, 2003-08-06 at 18:14, Tim Janik wrote:
> On 6 Aug 2003, Owen Taylor wrote:
> 
> > Hmm, so your plan is essentially (suppressing storing the
> > classes for each object for simplicity):
> >
> >  G_LOCK_DEFINE_STATIC (initializing_instances);
> 
> [...]
> 
> > (The initializing_instances_empty variable is actually superfluous, but
> > would be needed if you were using an array.)
> >
> > and the claim is that:
> >
> >  * If there are any objects being initialized in this thread, then
> >    this thread must see initializing_instances_empty as TRUE, since
> >
> >    *) After add_initializing_instance, it will be seen as TRUE
> >       by this thread
> >    *) No thread can set it FALSE until after this thread calls
> >       remove_initializing_instance on the object
> >
> > Yeah, I think that does work. It's not as quite as good as
> > ultra-fast thread-private-data (__thread) because it's certainly
> > possible to have an object that in its init does something slow
> > (reads in a big file fom disk, say), but probably good enough.
> >
> > Regards,
> > 					Owen
> >
> > [
> >   Does it make sense to use a separate lock rather than the
> >   global gtype reader-writer lock? I think it might, since
> >   avoiding write-locks when not actually modifying the type
> >   data is a good thing.
> > ]
> 
> ok, so you're arguing in favour of a seperate (static) lock for
> this. is this also arguing in favour of using a normal static lock
> vs. a static read-write lock? (note that we at least don't need
> to use a static lock if we forgo the rw-feature)

* I don't think a read-write lock is necessary here; there isn't
  a big asymmetry between reading and writing, and the lock is
  only held over short code sequences; I don't think there will
  be much contention for it even if you have a couple of threads
  that are doing nothing but create objects (not the normal case.)

  And normal mutexes are a bit smaller and more efficient. 

* For normal mutexes, static mutexes are more efficient than
  dynamically allocated mutexes and a lot easier to manage.
  That's why we use them in most places in GLib for locking
  global resources.

  Note that G_LOCK_DEFINE() and G_LOCK_DEFINE_STATIC() both
  define static mutexes, G_LOCK_DEFINE_STATIC() is just
  static G_LOCK_DEFINE(). Two different senses of the word
  static...

Regards,
					Owen