Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Subtle coding difference gives deadlock

I'm working on code that will be compiled for either JDirect-2 or JDirect-3
+ Carbon. To simplify my life (or so I thought at the time), I made a
class that effectively looks like this when compiled for JDirect-2:

class Carbonate
{
static Object LOCK = com.apple.mrj.macos.toolbox.Toolbox.LOCK;

static void acquire()
{ }

static void release()
{ }
}

and like this when compiled for JDirect-3:

class Carbonate
{
static Object LOCK = new Object();

static void acquire()
{ CarbonLock.acquire(); }

static void release()
{ CarbonLock.release(); }
}

This is pretty much what Mike Hall outlined earlier with his new approach,
though mine is strictly a statically compiled version.

Anyway, this is all prelude, because the Carbonate class is not the
problem. The problem is that code which looks like this works fine:

public final int
getSize()
{
int size;
synchronized ( Carbonate.LOCK )
{
try
{
Carbonate.acquire();
size = GetHandleSize( handle );
}
finally
{ Carbonate.release(); }
}
return ( size );
}

but WHAT SHOULD BE EQUIVALENT CODE ends up deadlocking:

public final int
getSize()
{
synchronized ( Carbonate.LOCK )
{
try
{
Carbonate.acquire();
return ( GetHandleSize( handle ) );
}
finally
{ Carbonate.release(); }
}
}

And technically, it's not really even deadlocking, because in MacsBug 'mrj
dl' detects no deadlocks. The clue is that 'mrj synccheck' shows a
"monitor problem":

Synchronization Problems:
thread: 0A954E68 "ConsoleThread"
state : WMON
wants : $a9f0ca8 : "com.apple.mrj.macos.toolbox.Toolbox@A8109F8/A810A00"
has mon : $a9f10e8 : "com.apple.mrj.console.Console@A7FD1E8/A7FD1F0"
has mon : $a9f05c8 : "java.lang.Class@A814C58/A814C60"

$a816388 -> com.apple.mrj.internal.awt.VFontPeer.<init>(VFontPeer.java)
$a816098 -> com.apple.mrj.internal.awt.VFontPeer.getPeer(VFontPeer.java)
$a810de0 -> com.apple.mrj.internal.awt.VToolkit.getFontPeer(VToolkit.java)
$a816110 -> java.awt.Font.initializeFont(Font.java)
$a816110 -> java.awt.Font.<init>(Font.java)
$a816098 ->
com.apple.mrj.internal.awt.VFontPeer.getDefaultWindowFont(VFontPeer.java)
$0 ->
com.apple.mrj.internal.awt.VFontPeer.setSwingMetalFontProps(VFontPeer.java)
$0 -> com.apple.mrj.internal.awt.VFontPeer.<clinit>(VFontPeer.java)
$a810de0 -> com.apple.mrj.internal.awt.VToolkit.getFontPeer(VToolkit.java)
$a810038 -> java.awt.Font.initializeFont(Font.java)
$a810038 -> java.awt.Font.<init>(Font.java)
$a80d1a0 -> com.apple.mrj.console.ConsoleLocalization.<clinit>(Console.java)
$a80bba8 -> com.apple.mrj.console.Console$ConsoleArea.<init>(Console.java)
$a7fd1e8 -> com.apple.mrj.console.Console.createConsoleWindow(Console.java)
$a7fd1e8 -> com.apple.mrj.console.Console.showHideConsole(Console.java)
$a7fd1e8 -> com.apple.mrj.console.Console.run(Console.java)
$a803bd8 -> java.lang.Thread.run(Thread.java)

I'll eventually file a full bug report on this, but I just wanted to let
everyone know that there's a problem either in the CW compiler's
code-generation for return within a synchronized try/finally block, or at
some other deadlock ambush point. It may be that the combination of the
synchronized block and the try/finally block must reach a certain
complexity before the problem arises, because other code that returns from
inside a synchronized block, but without try/finally, works fine.

The work-around is to NEVER RETURN FROM INSIDE THE BLOCK. This one simple
change makes all the code work perfectly so far. I've switched over to the
work-around throughout my current code, and it works great so far.

This is on MRJ 2.2.4, with MRJ 3.0 yet to be tested.

-- GG



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.