Re: Proposal: threads in glib.

[Owen Taylor <otaylor redhat com>]

Sebastian Wilhelmi <wilhelmi@ira.uka.de> writes:

> All of that leads me to the conclusion, that glib needs a simple, but
> powerfull thread abstraction.
> 
> I implemented such a beast in the spirit of glib, here's the README:
 
Some comments. 

* A GLIB API for threads need to be
  subsitutable at run time. That is, the application can
  provide a vtable of threading functions. The rational
  for this is that GLIB needs to interopt with systems
  that have there own threading. Examples of this are
  NSPR and Java.

  A patch that does this for the current GTK+ threading can
  be found at:

    ftp://ftp.gtk.org/pub/gtk/patches/gtk-rao-980914-0.patch.*

  My guess is that the synchronizaiton primitives should be 
  non-reentrant mutexes and condition variables. (NSPR
  has both, so they should be widely portable, or implementable
  on top of available constructs)

* I actually, think g_monitor_new_for_resource() is not
  as nice as NSPR's cached monitors. That is,
  if you aren't storing your per-resource monitors
  globally, than you have to always do:

  GMonitor *monitor = g_monitor_new_for_resource (resource);
  g_monitor_enter (monitor);

  [ ... ]

  g_monitor_leave (monitor);
  g_monitor_free (resource);

  Which is only marginally efficient than Netscape's 

    g_cached_monitor_enter (resource);
    [...]
    g_cached_monitor_leave (resource);
  
  and not nearly as convenient. If you are storing your
  monitors globally, than you can just use normal 
  monitors.

* It should be an error if g_monitor_free() is called on
  a monitor with ->entry_counter != 0. Your current
  code simply leaks the monitor in that case.

* g_monitor_wait(): I think it is
  incorrect for it to enter the monitor if the monitor is 
  not already locked by the current thread. In 99% percent
  of all cases, the programmer should be doing:

 g_monitor_enter (monitor);

 while (!some_condition)
   g_monitor_wait (monitor, 0);

 /* do something */
 g_monitor_leave (monitor);

Or something similar. If there is a valid reason
for ever doing:

 g_monitor_enter (monitor);
 g_monitor_wait (monitor, 0);
 g_monitor_leave (monitor);

(and I'm not sure there is) then the programmer can write
that explicitely.

[ 
  In your sources, you have the line:

      real->cond = new_cond; /* this should be atomic */

  I'm don't think atomicity is needed, but it is definitely
  not universally atomic. 
]

Regards,
                                        Owen