Re: multithreading and locking level

["Daniel Solaz" <dsolaz sistelcom com>]

Owen Taylor wrote:

>Can you provide examples of such other toolkit's? Xt and Motif
>just lock globally. (Well, they have "application" locks which
>are not completely global to the toolkit as well as global locks)

Yes.  The toolkit I was thinking about is called Trestle.  It is (or
better, it was) a research project from DEC SRC, a windowing system
designed to run on multiprocessors, thus completely thread-safe. IIRC it
had a global lock, but most of the time you were supposed to define
locking levels and ordering of locks so threads could progress in
parallel without deadlocking. I don't know if all this is really
implemented in the SRC Modula-3 Trestle lib (which is what I use).

For more about locking levels, see Extended Static Checking at
http://www.research.digital.com/SRC/esc/Esc.html, for Trestle itself:
http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/abstracts/src-rr-068.html
http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/abstracts/src-rr-069.html


>Someone once described how Windows do it, and it sounded like it
>basically just didn't lock widgets at all and left the user to make
>sure that they weren't accessing things in ways that would
>conflict.

Exactly what happens with Java Foundation Classes: in order to improve
performance, let's forget about the whole issue.  Not the best approach
when you are dealing with a multithreaded language (and one that is
proud of it -- both Java and Modula-3 are), IMHO.

How do the Java guys deal with all this?


>>In short, if two threads are working on completely unrelated parts of
>>the widget tree, can they work in parallel?  Or Xlib/GTK simply won't
>>accept it?

>It is not at all this simple. The problem is that interactions
>in GTK+ are not always up-and-down the widget tree.
>For instance, there are global resize and redraw queues, the entire
>mainloop is global, a Scrollbar can be connected to a Adjustment
>which is attached to a Text window somewhere completely independent
>in the widget heirarchy, etc...

That is one important difference.  GTK widgets can have graph-like
relationships; AFAIK Trestle widgets do not.

I guess that could be taken care of by defining standard techniques for
using the interface API: the Trestle guys went this way from the very
beginning, and it shows.

What then? A GTK (provider) thread delivering events from the mainloop,
and locking for redraws, and other (consumer) threads running event
handlers? Assigning unrelated widget sets to different threads?

It will be best if I first experiment a bit with some well known
approaches...

I don't know if Perl and ObjC bindings are affected by this.  How about
Guile bindings? I remember Guile had cooperative threads.  Do these
bindings deal with multithreading issues?


>The global lock currently in GTK+ works quite well. Trying to
>get more fine-grained locks would be a definite research project.
>I'm not sure the benefits are that big, either. The X protocol
>is only single threaded in the end, anyways. (The main place
>where you might have an advantage is if one thread is doing a
>long GTK+ operation like loading a big text file into a text
>widget, and another thread wants to draw to the screen)

A global lock is used by the Ada Motif bindings from Hans-Frieder Vogt,
too.  To begin with, the program calls X_Lib.Tasking.Resource.Seize.
Dead simple, really.

The single lock approach is fairly simple and enough for most
situations.  Those situations when I just use C.  But I'm thinking
about projects such as coding a whole OS/2 GUI clone, including
the multithreaded multiwindow file manager where even colors can
be dragged and dropped.  Where you probably have more than a few (dozen)
threads running.


-Daniel