• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

is ++x threadsafe?

 
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To all-
I have a class that updates a counter in a static class that holds a bunch of counter variables.
Multiple Message Driven Beans have the potential to update this particular counter using the pre-increment operator:
++x;
A coworker has pointed to a reference in a book where if you do this:
y = ++x;
the assignment can be preempted by another thread incrementing x before the assignment to y is complete.
Is this the case for ++x operation? Or is this considered an atomic work unit by the JVM and therefor not 'pre-emptable'?

Thanks,
Eric
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
x++ is not atomic. At least, not according to the spec, and I've verified that it can be interrupted when running J2SDK 1.3.1 on Windows 2000. (Yes, the variable x was declared volatile.) It's possible that the implementation is atomic for other JDKs or platforms, but you can't guarantee it. If it's important that your counter be exact, you'll have to synchronize the access.
 
eric mcentee
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Jim. Its not a big deal to make the change, I was just curious and couldn't find anything anywhere.
Thanks for sharing your insight.
 
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The atomicity of ++x is irrelevant. the complete operation
y=++x;
would have to be atomic. And of course its not. Even declaring x and y as volatile will not cause any thread safety. The only way to provide thread safety is with synchronize. No exceptions.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It didn't seem as though he was asking about y = ++x so much as just the ++x part of it. It sounded like the program he was interested in only had the ++x, while the book reference hady = ++x. In any event, since ++x itself is not atomic, y = ++x can't be either.
 
eric mcentee
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jim,
Thats correct, I was concerned about the ++x part. The assignment was covered in a thread book, but it never hurts to hear the ideas about it.
Thanks for everyones help.
- Eric
 
Bartender
Posts: 2205
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here's another quirky issue:
long x = 256;
long y = -1048;
x = y; //not atomic, so not thread safe!
reads and writes of 64 bit quantities are NOT required to be atomic in the spec. You have to either synchronize, or you can use the volitile keyword to force atomicity.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
According to the spec, volatile should force atomicity for loading and storing of 64-bit fields. But in practice, many JVM's don't actully implement this correctly. See Peter Haggar's posts here for more info.
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rob Ross:
Here's another quirky issue:
long x = 256;
long y = -1048;
x = y; //not atomic, so not thread safe!
reads and writes of 64 bit quantities are NOT required to be atomic in the spec. You have to either synchronize, or you can use the volitile keyword to force atomicity.



Again, whats the objective? the only way to ensure a proper value is synchronize, volatile will not give you the necessary multithreaded protection. volatile will prevent rediculous numbers that never occured in your program, but it won't let you safely read or write the variable.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, there are cases where volatile could actually be useful if it were implemented correctly. For example if most threads are interested only in only atomic operations like reading a variable, volatile can be a faster way for them to access the variable, and still safe. E.g. I might have a long field representing a timestamp - time of last modification or some such. Maybe many threads want to check this stamp regularly, and only a few will be changing it. The changers may require synchronization to safely make changes, but the readers would be OK with just making the field volatile. (At least, they would if volatile weren't broken.)
In general, even if volatile is implemented correctly its usefulness is limited at best, and it's very easy for people to make subtle mistakes with it which make their programs unreliable. So it should be avoided unless the user is very sure of what they're doing. And given the current implementation problems, it should really be completely banned from programs. But who knows, they might fix it someday, so that it's only useless 95% of the time... :roll:
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jim Yingst:
Well, there are cases where volatile could actually be useful if it were implemented correctly. For example if most threads are interested only in only atomic operations like reading a variable, volatile can be a faster way for them to access the variable, and still safe.


Watch your tone mister! volatile is not broked, JVMs are broken
In your example I can not understand why you would use any synchronization at all. You obviously dont care to get an exact value from the variable, and if you can write without the write breaking(because of volatile ) then you don't even need to synchronize.
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
eric, I see your question now, and I understand why you would ask it. I have seen certain environments in which ++x is the only atomic command, so I often look for that when I am using a new environment. But in java ++x is not an atomic command according to the JLS. I don't think it will ever be. you are stuck with using synchronize.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"Volatile is broken" was intended as shorthand for "volatile is implemented incorrectly on many JVMs".
In your example I can not understand why you would use any synchronization at all.
Yeah, in this particular example I guess the setters wouldn't need any synchronization, if the JVM were to implement volatile correctly. :roll: I had originally been thinking of a slightly different example, but altered it before I submitted the post, and neglected to bring all my comments into sync with the new example.
 
reply
    Bookmark Topic Watch Topic
  • New Topic