[concurrency-interest] synchronization edge case

[David Holmes]

Dhanji,

synchronized(Thread.class) does not call Object.wait(), it simply acquires
the monitor associated with the Thread Class object. This will lock out all
code that also wants to acquire this monitor.

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).

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.

Cheers,
David Holmes
  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Dhanji R.
Prasanna
  Sent: Tuesday, 24 April 2007 1:27 PM
  To: concurrency-interest
  Subject: [concurrency-interest] synchronization edge case


  Hi

  I cite this puzzle from Josh Bloch and Neal Gafter's "Java Puzzlers:"

  synchronized(Thread.class) {
      Thread.sleep(Long.MAX_VALUE);
  }

  I tested this on a webapp deployed into BEA weblogic and it basically
locks down the entire server so that it is effectively dead (doesnt startup,
doesnt accept new deployments, doesnt service any requests, doesnt
shutdown). Java EE servers are supposed to prevent such malarkey by
installing securitymanagers that restrict (direct) access to threading apis.
But how would one do so in such a case?

  I assume that internally synchronized(Thread.class) calls Object.wait(),
so is there a way to lock out wait() without AOP-style interception?

  Dhanji.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070424/850819ce/attachment.html