|
From: | Bryce McKinlay |
Subject: | Re: Unstructured locking bug |
Date: | Mon, 14 Mar 2005 13:07:31 -0500 |
User-agent: | Mozilla Thunderbird 1.0 (X11/20041206) |
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 oflocks: 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
[Prev in Thread] | Current Thread | [Next in Thread] |