WRT to volatile.
Is there anyway to extend the notion/contract of volatile to access to array elements. So of course volatile int[] arr = new int[2]; Just offers the contract to the array reference 'arr' What about multiple threads wanting some contract between their uses of arr[1] and arr[2]? Just thought I would throw this into the mix.. Gary -----Original Message----- From: core-libs-dev-boun...@openjdk.java.net [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of Brian Goetz Sent: Friday, February 07, 2014 2:45 PM To: Doug Lea; core-libs-dev Subject: Re: Draft JEP on enhanced volatiles It's about time we brought atomic ops out of the shadows of Unsafe and into the programming model proper! It was a good compromise ten years ago to stuff these into Unsafe, but its time for these features to grow up. Specific to this proposal, I like how the VolatileXxx interface approach allows us to add new fencing modes and/or atomic operations should we discover that the initial set is deficient. I also like how this potentially gives us a consistent story for volatile semantics on array elements. I can see a clean and straightforward implementation here at all the required touch points: language spec, memory model, type system, compiler, and VM runtime, and none of them require any special magic. (Having spent some time exploring this design space myself, I think the proposed surfacing is the least objectionable and most transparent of the options that I've seen.) Minor nits called out inline. Otherwise, Reviewed (as JDK reviewer) and Endorsed (as area lead). > We then enable access to corresponding methods for (typically > volatile) fields using the ".volatile" prefix. For example: Is this a prefix or a suffix? > The ".volatile" syntax is slightly unusual, but we are confident that > it is syntactically unambiguous and semantically specifiable. And, it is reasonably consistent with other similar uses of keywords for qualifying access to functionality, such as I.super or Outer.this. > We also expect to allow volatile > operations on array elements in addition to fields. This calls for the memory model to provide clear semantics for mixed accesses, such as volatile write / nonvolatile read. (The same would be true if we permitted the use of the .volatile modifier on nonvolatile fields.) > Several other alternatives > (including those based on field references) have been raised and > dismissed as unworkable on syntactic, efficiency, and/or usability > grounds or extensibility grounds. Many existing proposals might work for the operations in front of us today, but not scale as new fencing modes or atomic operations are discovered. > Risks and Assumptions > --------------------- > > We are confident of feasibility. However, we expect that it will > require more experimentation to arrive at compilation techniques that > result in efficient enough implementation for routine use in the > performance-critical contexts where these constructs are most often > needed. The use of method handles may be impacted by and may impact > JVM method handle support. As a limitation, I'd call out that its not obvious how this would scale to DCAS. > A large number of usages in java.util.concurrent (and a few elsewhere > in JDK) could be simplified and updated to use this support. Hooray!
