[concurrency-interest] synchronization edge case

David Holmes dcholmes at optusnet.com.au
Tue Apr 24 00:26:00 EDT 2007


Ah I see it. Yes Thread creation will be locked-out because it requires
getting the next thread-ID and/or thread-number which is obtained via a
static synchronized method and hence needs the monitor of the Class object.
We probably should have used an AtomicLong/AtomicInteger for those.

Really, as a matter of robustness, no library class should use a publicly
accessible object for its locking - except as part of an explicit protocol.

Cheers,
David Holmes
  -----Original Message-----
  From: Dhanji R. Prasanna [mailto:dhanji at gmail.com]
  Sent: Tuesday, 24 April 2007 2:10 PM
  To: dholmes at ieee.org
  Cc: concurrency-interest
  Subject: Re: [concurrency-interest] synchronization edge case





  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--but
since 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.



  Dhanji.

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


More information about the Concurrency-interest mailing list