'I-lock-I-do-I-unlock' vs 'I-unlock-others-lock-others-do-others-unlock-I-lock'

["Daniel Solaz" <dsolaz sistelcom com>]

Well, I've rediscovered and (re-?) read the thread on GTK's
thread-safety that took place in this list from May 8th to 16th...
everything I need is there.

I also took a look at Owen's gtkthreads (thanks Max).
Is all this already done for 1.1?  And how, exactly?  How was the
problem with idle functions solved?

Anyway, I'll implement this all using Modula-3's native thread API,
mutexes and conditions, and I find myself wondering:

Which is the right locking policy?
1) I-lock-I-do-I-unlock
   This is what I found myself doing: explicitly lock whenever there's
   need to.  Easier for others to acquire the lock, and you know that
   you must acquire it before doing any GTK work, but I have to make
   sure the thread calling gtk_main_iteration also acquires such lock.
   I would like to know if is it ok to have the GTK thread do
   lock-while(events_pending)main_iteration-unlock, or performance
   will suffer with respect to lock-main-unlock?
   Single-threaded apps could ignore the whole thing and do gtk_main
   anyway... possibly calling Gtk.Init(Gtk.Threading.Single) (this
   would be the default, I guess).
2) I-unlock-others-lock-others-do-others-unlock-I-lock
   This is what GTK does, according to messages I've read; I assume I
   hold the GTK lock, so I don't have to lock and unlock all the time,
   but I have to know where to unlock (m3 won't let me acquire a mutex
   I already hold) and where not to, in order to avoid deadlocks.
   Single-threaded apps do as usual, right?

Comments, flames and suggestions are welcome.

Thanks in advance.
-Daniel