Re: multithreading and locking level

[Owen Taylor <otaylor redhat com>]

"Daniel Solaz" <dsolaz@sistelcom.com> writes:

> I'm trying to find out how to best set up GTK bindings for multithreaded
> languages.
> 
> Basically, until we have a thread-safe GTK, it seems that one either
> sets up a proxy thread (I'm not going to discuss this now) OR...
> 
> >This wouldn't work for our purposes.  The second approach allows you
> >to call gtk (or X) functions from any thread, but it requires some
> >careful synchronization.  The basic idea is that you create an X
> >protection mutex, and *no one* may make *any* X calls without first
> >acquiring this mutex.  So if you want to draw a line, you have to say:
> >...
> (Rob Browning, 'Re: thread safe gtk?', May 8th)
> 
> As Mr. Browning says, there's more to it that just happily locking and
> unlocking some Gtk.Lock as needed.
> 
> Here's what I'd like to try, based on other toolkit's approach as seen
> elsewhere:

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)

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.
 
> Would it be safe to have *each* widget wrapper inherit from MUTEX, and
> acquire this lock (not the global Gtk.Lock) before use?
> Since widgets form a tree-like hierarchy, before affecting widget w I
> guess I would need to lock the whole branch starting at w so that no
> concurrent calls to Gtk act on the same widget (or a related one) at the
> same time.
> Locking would have to be done starting at the leafs of the branch, and
> proceed upwards until w.lock can be acquired (that is, first w's
> children, recursively, then w).  Unlocking would be done from w
> downwards, then.
> 
> 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...

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)

Regards,
                                        Owen