[Sebastian Wilhelmi <wilhelmi@ira.uka.de>] [ Proposal: threads in glib ]

[Owen Taylor <otaylor redhat com>]

------- Start of forwarded message -------
Message-ID: <365282D2.D01D308D@ira.uka.de>
Date: Wed, 18 Nov 1998 09:18:26 +0100
From: Sebastian Wilhelmi <wilhelmi@ira.uka.de>
Organization: IRF Uni Karlsruhe
To: otaylor@redhat.com
Subject: Re: You have been removed from the list
References: <19981117030948.25753.qmail@mail2.redhat.com>

Hi, Owen

Sorry for replying so late, but your mail never made it to me, there have
been some problems with our mail system recently and I actually got this
message as a `Your mail address ... has been removed` type of message,
anyway here we go:

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

Thanks.

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

Yes, sure.

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

depends on how your using it. But I see your point.

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

Yes.

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

You could do such a thing if you just want to syncronise threads without
the need to do some data protection. 

>[ 
>  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. 
>]

it is just that in another place this variable is checked to be non-NULL
and then a notify is issued, otherwise it isn't (becuase nobody's waiting
on that condition)

But now some general notes: My views on that matter has actually changed.
They are now as follows:

- glib should be ALWAYS (if possible, that is, see later) MT-safe (not
meaning that you can safely operate on e.g. two hash-tables form different
threads, but that you can safely do a g_hash_table_new from two threads,
which is basically unsafe now, due to chunkks etc., as you certainly are
aware of)

- programs using glib should not be forced to link to whatever thread
library. because some systems (solaris, aix, do not know about linux) need
special startup code for mt-applications. This is unnecessary and unwanted
overhead for the average glib user.

- all other threading issues should be put into another library.

that all lead me to the following conclusion:

- put assembler spinlock snippets into glib. (see
http://goethe.ira.uka.de/~wilhelmi/gnome/gthread.html for an example, the
snippets themself are however 'stolen' from the linuxthread package. I
only adapted them a bit. There are snippets for alpha, i386, mips, m68k,
ppc, sparc). those will then be put around the use of every static var in
glib etc. 

- those spinlocks are extremly fast, as long as there are no clashes, but
they on the other hand are extremly rare.

- non-gcc compilers will not get MT-safety, as they do not have the same
asm syntax as the gcc. for important compilers we can of course adapt the
system.

- you get the MT-safe support for win32 for free (if using gcc there, at
least)

- we then have a thread-safe and fast glib without requiring too much of
the system. I do not if spinlocks would suffice in gtk, or if mutexes are
necessary, because of the potentially long waiting time, but it might
definitly be worth a look: if spinlocks would be enough too, the whole
thing could be done LEAN and FAST. and thats what we all want, don't we?

Hope to hear from you.

BTW.: I haven't got any replies to my proposal, not even yours (I mean
directly through the mailing list). I hope not to have left too many
replies unanswered. there's no gtk-devel-list-archive, is there?

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 <-----------------+
------- End of forwarded message -------