aspose file tools*
The moose likes Threads and Synchronization and the fly likes Question on Volatile Variable Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Question on Volatile Variable" Watch "Question on Volatile Variable" New topic
Author

Question on Volatile Variable

Jack Nam
Ranch Hand

Joined: Feb 09, 2010
Posts: 33
Hi Everybody,

If I access an instance of sequenceValue like below. Is it safe? should I make nextVal variable volatile?

synchronized(sequenceValue){
long newVal = sequenceValue.getNextVal();
}


class SequenceValue {

long nextval = 0;

public long getNextval() {
return nextval++;
}


}
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2267
    
    3

Hum... I don't think this question has something to do with the SCJD certification. So, let's slide this over to the Threads and Synchronization forum!

Ah, and by the way, you just have to synchronize on objects that may be accessed by more than one Thread, and you have to do this in order to protect their state. So, I'd say that this code of yours is thread-safe and you don't have to make it volatile. But, in order to always be thread-safe, you always have to synchronize on the sequenceValue object.


Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
Jack Nam
Ranch Hand

Joined: Feb 09, 2010
Posts: 33
I did googling on this topic, and it is kind of grey to me. Although the sequenceValue is thread-safe, but I wonder if the property is. It could be like a volatile array, not thread-safe for the element.
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3649
    
  17

No, you don't have to make it volatile. After a synchronized block exits, changes to the state of the object that was synchronized on will immediately be visible to all subsequent inspections of the object. Hence the word "synchronized".

Volatile is only needed when you access a primitive with multiple threads, through unsynchronized code.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Jack Nam wrote:Although the sequenceValue is thread-safe, but I wonder if the property is. It could be like a volatile array, not thread-safe for the element.

I would say that the code show is thread-safe if used as shown here. However nothing seems to prevent other code from calling getNextValue() in an unsafe manner, without synchronizing. It would be better to write getNextValue() so that it is always thread-safe. You can achieve this by putting the synchronization inside the method, such that anyone calling the method will activate the synchronization. This can be done with a synchronized block, or you can just synchronize the getNextValue() method itself.
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2267
    
    3

Mike Simmons wrote:I would say that the code show is thread-safe if used as shown here.


Agreed.

Mike Simmons wrote:However nothing seems to prevent other code from calling getNextValue() in an unsafe manner, without synchronizing.


Agreed, that's why I said above that "in order to always be thread-safe, you always have to synchronize on the sequenceValue object".
Jack Nam
Ranch Hand

Joined: Feb 09, 2010
Posts: 33
Ok guys.

Noticed. Thanks.
Anupam Sinha
Ranch Hand

Joined: Apr 13, 2003
Posts: 1088
I think that the code is not thread safe.

This simple looking line



is not thread safe. Java only guarantees a 32 bit to be atomic (unless otherwise made atomic). So nextVal should be made volatile.

Apart from this I am not able to understand this program much.

I am unable to understand how this program (barring the above reason) will be thread safe (if it is made to compile).

getNextval is not synchronized so even acquiring a lock on sequenceValue shouldn't matter much.
Jack Nam
Ranch Hand

Joined: Feb 09, 2010
Posts: 33
if >> synchronized getNextval is thread-safe. Then the equivalent synchronized(this) inside getNextval is also safe. Then synchronized(sequenceval) is also safe since those statements are synonym.

Anupam Sinha wrote:I think that the code is not thread safe.

This simple looking line



is not thread safe. Java only guarantees a 32 bit to be atomic (unless otherwise made atomic). So nextVal should be made volatile.

Apart from this I am not able to understand this program much.

I am unable to understand how this program (barring the above reason) will be thread safe (if it is made to compile).

getNextval is not synchronized so even acquiring a lock on sequenceValue shouldn't matter much.
Anupam Sinha
Ranch Hand

Joined: Apr 13, 2003
Posts: 1088
What if someone accesses sequenceValue.getNextVal(); directly without the lock?
Jack Nam
Ranch Hand

Joined: Feb 09, 2010
Posts: 33
then it would not be thread-safe.

Anupam Sinha wrote:What if someone accesses sequenceValue.getNextVal(); directly without the lock?
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Anupam Sinha wrote:Java only guarantees a 32 bit to be atomic (unless otherwise made atomic). So nextVal should be made volatile.

Volatile will never make a ++ operation atomic, for long or any other primitive data type. The ++ operation requires that the value be read, modified, and written - that's never atomic according to volatile's rules.

I think everything else I might add has already been said several times at this point. It's thread-safe in the code here only because of the synchronized, and it's easy to (accidentally or intentionally) bypass that and make the code unsafe.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Question on Volatile Variable