[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unstructured locking bug

From: Etienne Gagnon
Subject: Re: Unstructured locking bug
Date: Mon, 14 Mar 2005 17:04:06 -0500
User-agent: Debian Thunderbird 1.0 (X11/20050117)

Here's what the JNI spec says about it:


 Prototype jint MonitorExit(JNIEnv *env, jobject obj);


 Native code must not use MonitorExit to exit a monitor entered through
 a synchronized method or a monitorenter Java virtual machine

So, the current AWT code clearly does something that the JNI spec does
not allow for.

As for structured locking, it isn't obvious to me that a VM "may not"
impose it on monitors of "native" frames.  This could be the subject of
a long debate, which is not needed here, as the JNI spec has different
provisions that forces a redesign of the current algorithm.

In general, writing unstructured locks is a recipe for getting into
trouble (deadlocks, illegal monitor states, etc).  Depending on a "depth
1" is a trouble in itself, as there's nothing preventing deeper locking
depth on java (& JNI) monitors.  If such "weird" thing is required, I
would suggest to simply build the required locks a "self preserving"
higher-level constructs.


class OneLevelLock
  private Object internalMonitor = new Object();
  private Thread owner = null;

  public lock()
      if (owner != null)
        throw IllegalMonitorState(
          "attempt to lock deeply");

      owner = Thread.getCurrentThread();

and use JNI to call the lock/unlock methods of this "robust" one-level
lock (for which structured locking is not required).


Bryce McKinlay wrote:
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?


Etienne M. Gagnon, Ph.D.  

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]