JDK-4748143 : Add C#'s Monitor.TryEnter method to synchronized blocks
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Affected Version: 1.4.1
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-09-16
  • Updated: 2007-06-23
  • Resolved: 2007-06-23
Related Reports
Duplicate :  
Description

Name: nt126004			Date: 09/16/2002


FULL PRODUCT VERSION :
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-rc-b19)
Java HotSpot(TM) Client VM (build 1.4.1-rc-b19, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]

ADDITIONAL OPERATING SYSTEMS :

All


A DESCRIPTION OF THE PROBLEM :
The Monitor.TryEnter method in .NET is brilliant.  It allows you to set up a synchronized block that gets skipped if the lock is in use, otherwise it will acquire the lock and continue.  It has both a default version and a timeout version.
Here is an example from the help using the default version:

    //Check if the queue is locked.
    if (Monitor.TryEnter(m_inputQueue) == False)
      {
        AddElementWithoutWait = False;
      }
    else
      {
        m_inputQueue.Enqueue(qValue);
        Monitor.Exit(m_inputQueue);
      }


The other version(s) of TryEnter allow you to pass in a time to wait for the lock.  This would be a great feature to be able to use even just for things like threading in Swing.  It is not 'syntactic sugar' as far as I can tell.
(Review ID: 164171) 
======================================================================

Comments
EVALUATION JSR166 did indeed add equivalent functionality, in the context of java.util.concurrent.Lock, but not for builtin Java monitors. See Lock.tryLock http://java.sun.com/javase/6/docs/api/java/util/concurrent/locks/Lock.html#tryLock()
23-06-2007

EVALUATION We are considering additional concurrency support in the context of community process (JSR166). ###@###.### 2002-09-25
25-09-2002