[concurrency-interest] synchronization edge case

Dhanji R. Prasanna dhanji at gmail.com
Tue Apr 24 00:10:18 EDT 2007

On 4/24/07, David Holmes <dcholmes at optusnet.com.au> wrote:

> I don't have puzzlers so don't know what the "trick" is with this one. I
> couldn't see any explicit acquisitions of this monitor in the JDK library
> code. That leaves the implicit ones - the only one of which I'm aware of is
> class loading of the Thread class. But as that is done early in the VM
> bootstrap it should not be an issue unless your are running newly loaded
> classes with unresolved references to the Thread class *and* the VM
> explicitly locks the Class object during resolution (which isn't actually
> necessary and the next edition of the JVMS will clarify this).

Here is my understanding:
During creation of new threads, the api synchronizes on
Thread.class--butsince it is already locked, they enter the queue
behind it (I assumed it was
Object.wait() style behavior). So no new threads can be created (existing
threads still run ok) and that renders the app server more or less
useless--depending on what stage this code is executed at.

But what you are basically asking is: is there a way to prevent a thread
> from acquiring the monitor of a "critical" object? And the answer is no -
> not within the language or core API's.

Ok this is good to know! Somewhat of a serious hole in appserver security,
though a bit of an edge-case. I wonder if this can be mitigated with the EE
app verifier or some such intermediary that ensures against access to
restricted apis?

Thanks David.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070424/3ad5bec1/attachment-0001.html 

More information about the Concurrency-interest mailing list