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

Boehm, Hans hans.boehm at hp.com
Mon May 11 15:42:55 EDT 2009


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
> 


More information about the Concurrency-interest mailing list