JDK-4709728 : ConditionVariables
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.2
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: x86
  • Submitted: 2002-06-28
  • Updated: 2003-08-20
  • Resolved: 2003-08-20
Related Reports
Duplicate :  
Description
> Doug Lea wants the HotSpot work for JSR-166 to not fall off our radar.
> JSR-166 is NOT the New Memory Model, that's already come to pass.
> JSR-166 is bunch of things that build on the New MM to allow highly
> concurrent abstract data types.  He needs a reference implementation
> to get the changes approved and "we're it".
>
> In particular he needs:
> (3) Non-nested locks for ConditionVariables.  This would have been tough
>     EXCEPT such access already exists in the Unsafe class.  Naturally we
>     must inflate such locks on the spot (as the backing stack store will
>     disappear when we exit), but this is OK because the expected usage
>     for these locks is to actually block.

Comments
EVALUATION Implementing condition variables does require VM support, however it does not necessarily require non-nested locks; the alternative is to modify the VM spec to provide explicit support for condition variables, i.e., multiple wait-sets associated with the same lock. The latter solution is arguably cleaner and might also be faster (as it translates more directly to pthreads). ###@###.### & ###@###.### 2002-07-25 The changes for JSR-166 have been consolidated under one bugid: 4904703. I am closing this bug as a duplicate of 4904703. ###@###.### 2003-08-19
25-07-2002