aspose file tools*
The moose likes Threads and Synchronization and the fly likes is ++x threadsafe? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "is ++x threadsafe?" Watch "is ++x threadsafe?" New topic
Author

is ++x threadsafe?

eric mcentee
Ranch Hand

Joined: May 02, 2001
Posts: 66
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
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
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.


"I'm not back." - Bill Harding, Twister
eric mcentee
Ranch Hand

Joined: May 02, 2001
Posts: 66
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.
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

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
Sheriff

Joined: Jan 30, 2000
Posts: 18671
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

Joined: May 02, 2001
Posts: 66
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
Rob Ross
Bartender

Joined: Jan 07, 2002
Posts: 2205
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.


Rob
SCJP 1.4
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
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

Joined: Oct 05, 2001
Posts: 1170

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
Sheriff

Joined: Jan 30, 2000
Posts: 18671
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

Joined: Oct 05, 2001
Posts: 1170

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

Joined: Oct 05, 2001
Posts: 1170

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
Sheriff

Joined: Jan 30, 2000
Posts: 18671
"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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: is ++x threadsafe?