Re: Unstructured locking bug

[Bryce McKinlay]

Etienne Gagnon wrote:

> Recent gtk peer code seems to have introduced a subtle bug, only visible
> on VM's that verify that structured locking is properly done.  I have
> put a description of the bug in the bug tracker at:
>
> http://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=12301
>
> There seems to be an easy fix:
> 1- *Remove* the MonitorExit() ... MonitorEnter() calls [yes, they're in
> that order!]
> 2- Document somewhere (in the awt/gtk documentation) the hierarchy of
> locks: one must release the GDK lock before acquiring the EventQueue 
> lock,


iterateNativeQueue() needs to behave like wait(), because we need to 
allow threads to post events to the Java event queue while the 
EventDispatchThread is blocked in the GTK main loop. gtk_main_iteration 
could potentially block forever if there is no human/external event 
input, so other threads wishing to post events to the queue will block. 
For example: if the lock is not released, a thread drawing animations 
based on a timer wouldn't work correctly unless there is constant GTK 
event input because the "animation thread" would be blocked on postEvent().

I agree this approach is flakey, though - it isn't going to work if the 
queue lock is held at (depth > 1), and currently that is  possible 
because it is a user-visible lock.

Certainly, bytecode isn't allowed to do this kind of thing, but I'm not 
sure if the structured locking rules in the VM spec are meant to apply 
to native code. For example, wait() would be impossible to implement if 
this were the case, wouldn't it?

Bryce