[concurrency-interest] Concurrency-interest Digest, Vol 52, Issue 1

David Holmes davidcholmes at aapt.net.au
Tue May 12 03:22:14 EDT 2009


But in the context of choosing volatile over synchronized, volatile can be
cheaper because synchronized always has the same memory synchronization
affects as a volatile-read _and_ a volatile-write.

However, for cases where volatile is an alternative to synchronized, it is
contention costs that would be the dominant consideration.

David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Brian
> Goetz
> Sent: Tuesday, 12 May 2009 5:13 PM
> To: Boehm, Hans
> Cc: Bharath Ravi Kumar; concurrency-interest at cs.oswego.edu; Tim Peierls
> Subject: Re: [concurrency-interest] Concurrency-interest Digest, Vol 52,
> Issue 1
>
>
>
> Or, to simplify further: volatile reads cheap, volatile writes expensive.
>
> Boehm, Hans wrote:
> > This is highly hardware-specific.  In most cases, volatile
> accesses should be appreciably cheaper than acquiring and
> releasing a lock.  (Since they can by implemented by acquiring
> and releasing a lock, they certainly shouldn't be appreciably worse.)
> >
> > On X86, a volatile load should cost roughly the same as an
> ordinary load, but a volatile store is appreciably more
> expensive, and will probably cost close to the time it takes to
> acquire a lock.  But even there, cycle counts for volatile stores
> will differ by up to a decimal order of magnitude (roughly 10 to
> 100 without cache misses) depending on the specific processor
> microarchitecture.  And there may be hope that this overhead
> might decrease in the future, since most current hardware ISAs
> don't appear to be a great match for recently redesigned
> programming language memory models.  (Disclaimer: I'm not a
> hardware architect, and don't really know what they're up to.)
> >
> > Hans
> >
> >> -----Original Message-----
> >> From: concurrency-interest-bounces at cs.oswego.edu
> >> [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf
> >> Of Michael Lee
> >> Sent: Monday, May 11, 2009 5:24 AM
> >> To: Tim Peierls
> >> Cc: Bharath Ravi Kumar; concurrency-interest at cs.oswego.edu
> >> Subject: Re: [concurrency-interest] Concurrency-interest
> >> Digest, Vol 52, Issue 1
> >>
> >> Can I assume that read/write volatile variable is expensive?
> >>
> >> I was told that it depends on the hardware platform but I am
> >> getting conflicting information.  In the old version JSR133
> >> FAQ, it said that volatile is expensive.  But now it has been
> >> corrected to say it is not expensive.
> >>
> >> What kind of overhead do I expect to see with using volatile?
> >>  I know that we should not assume until we measure but it
> >> will nice to know the trade-off using volatile /
> >> synchronization when creating a new class...
> >>
> >> Thanks
> >>
> >> - Michael
> >>
> >> On Sun, May 3, 2009 at 8:24 AM, Tim Peierls <tim at peierls.net> wrote:
> >>> Reads and writes of volatiles have memory effects under the
> >> JMM. The
> >>> idiom described in EJ2e, Item 71 minimizes the number of volatile
> >>> reads and writes through the use of a temporary variable.
> >> Josh Bloch
> >>> says (in Item 71) that on his machine this code was 25
> >> percent faster
> >>> than the obvious version with no temporary variable. Item
> >> 71 also has
> >>> good advice about when the use of this idiom is appropriate.
> >>> --tim
> >>>
> >>> On Sun, May 3, 2009 at 6:12 AM, Bharath Ravi Kumar
> >>> <reachbach at gmail.com>
> >>> wrote:
> >>>> Hi Tim,
> >>>>
> >>>> How does the local variable tmp help? Why not carry out a
> >> null checks
> >>>> on (and subsequent assignment to) resource directly? Does
> >> the usage
> >>>> of tmp reduce contention in any manner? Could you please explain?
> >>>>
> >>>> Thanks,
> >>>> Bharath
> >>>>
> >>>>
> >>>>> From: Tim Peierls <tim at peierls.net>
> >>>>> Subject: Re: [concurrency-interest] Reordering
> >> clarification in DCL
> >>>>>        example
> >>>>> To: Carol Saah <csaah at cox.net>
> >>>>> Cc: concurrency-interest at cs.oswego.edu
> >>>>> Message-ID:
> >>>>>
> >> <63b4e4050905020938u5c4ba444vec35d2ef003a5d11 at mail.gmail.com>
> >>>>> Content-Type: text/plain; charset="iso-8859-1"
> >>>>>
> >>>>> See more recent discussions in Java Concurrency in
> >> Practice, Section
> >>>>> 16.2.4
> >>>>> and Effective Java, 2nd edition, Item 71.
> >>>>> The fixed version of the code is:
> >>>>>
> >>>>> class SomeClass {
> >>>>>  private volatile Resource resource;
> >>>>>
> >>>>>  public Resource getResource() {
> >>>>>    Resource tmp = resource;
> >>>>>    if (tmp == null) {
> >>>>>      synchronized (this) {
> >>>>>        tmp = resource;
> >>>>>        if (tmp == null)
> >>>>>          resource = tmp = new Resource();
> >>>>>      }
> >>>>>    }
> >>>>>    return tmp;
> >>>>>  }
> >>>>> }
> >>>>>
> >>>>> --tim
> >>>
> >>> _______________________________________________
> >>> Concurrency-interest mailing list
> >>> Concurrency-interest at cs.oswego.edu
> >>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >>>
> >>>
> >> _______________________________________________
> >> Concurrency-interest mailing list
> >> Concurrency-interest at cs.oswego.edu
> >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >>
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest




More information about the Concurrency-interest mailing list