1

e.g. I have static field in multithreading enviroment (many threads use this variable):

public static int value;

Should I add volatile to declaration to establish a happens-before relationship?

Lies
  • 303
  • 4
  • 11
  • Check out this question for possible problems: http://stackoverflow.com/questions/13374988/java-is-there-a-right-way-to-use-static-volatile-variables – default locale Feb 26 '13 at 10:05
  • 3
    Adding volatile would indeed establish a happens-before relationship. But without more context, it's impossible to say if that would be sufficient to make the code correct. – JB Nizet Feb 26 '13 at 10:06
  • @defaultlocale, it is not the same, my question is about necessity of volatile variable. – Lies Feb 26 '13 at 10:07
  • 1
    Please take a look at this http://stackoverflow.com/questions/5451802/can-volatile-variable-be-defined-as-static-in-java – Nidhish Krishnan Feb 26 '13 at 10:08

2 Answers2

3

Instance association is orthogonal to concurrent modification.

if you access a static values through multiple thread each thread can have it's local cached copy To avoid this you can declare the variable as static volatile and this will force the thread to read each time the global value

TheWhiteRabbit
  • 15,480
  • 4
  • 33
  • 57
  • You are sure, that different threads can have caches value of static variable? – Lies Feb 26 '13 at 10:09
  • 2
    @Lies: yes, TheWhiteRabbit is absolutely right. If he wasn't volatile would be completely useless (except for double and long variables), since its only effect is precisely to ensure a happens-before relationship, i.e. to make sure a thread can't see an obsolete cached value. – JB Nizet Feb 26 '13 at 10:13
2

Yes, that would be one way of doing it. Another way would be to access it using synchronized methods only.

Volatile fields are special fields which are used for communicating state between threads. Each read of a volatile will see the last write to that volatile by any thread; in effect, they are designated by the programmer as fields for which it is never acceptable to see a "stale" value as a result of caching or reordering. The compiler and runtime are prohibited from allocating them in registers. They must also ensure that after they are written, they are flushed out of the cache to main memory, so they can immediately become visible to other threads. Similarly, before a volatile field is read, the cache must be invalidated so that the value in main memory, not the local processor cache, is the one seen. There are also additional restrictions on reordering accesses to volatile variables.

http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#volatile

Note that if you also want atomicity in addition to the happens-before relationship, read the answer to this question : Java: Is there a right way to use static volatile variables?

Community
  • 1
  • 1
lbalazscs
  • 17,474
  • 7
  • 42
  • 50
  • 1
    @giorashc: it depends what you do in the methods accessing it. Simply doing `value++` would lead to a different behavior between synchronized access and non-synchronized access but volatile. – JB Nizet Feb 26 '13 at 10:07