> > Is there anyway to extend the notion/contract of volatile to access to > array elements.
>From Doug's original email We also expect to allow volatile operations on array elements in addition > to fields. I'm quite excited about these changes, it looks like a great way to provide support outside of unsafe. On 7 February 2014 21:25, Frost, Gary <gary.fr...@amd.com> wrote: > > > 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! > > > >
