synchronized

[mike7411]

Let's say you have an integer called progress which represents a
thread's progress (from 0 to 100 percent).

A worker thread sets this progress variable.

Another thread reads the progress variable and simply displays it.

Is there any need for the synchronized keyword in writing this code?

Thanks.

 

[Andreas Leitgeb]

Let's say you have an integer called progress which represents a
thread's progress (from 0 to 100 percent).
A worker thread sets this progress variable.
Another thread reads the progress variable and simply displays it.
Is there any need for the synchronized keyword in writing this code?

Not synchronized, but "volatile", to prevent the reader
from possibly optimizing away the actual variable access.

 

[John B. Matthews]

Not synchronized, but "volatile", to prevent the reader
from possibly optimizing away the actual variable access.

If I may amplify, the new value must not depend on the previous value:

<http://www.ibm.com/developerworks/java/library/j-jtp06197.html?S_TACT=105AGX02&S_CMP=EDU>

 

[Mark Space]

If I may amplify, the new value must not depend on the previous value:

<http://www.ibm.com/developerworks/java/library/j-jtp06197.html?S_TACT=105AGX02&S_CMP=EDU>

To the OP: That link there talks about visibility, which is the other
issue. Synchronization does more in Java than just guarantee mutual
exclusion. It also manages where and when your variable(s) is visible to
other threads.

Imagine that you have, not just multiple threads, but multiple CPUs.
Each CPU has it's own cache internally. If you have one thread, reading
modifying and writing a variable it's possible that the variable is only
modified by the one CPU, and it's values never leave the caches.

Synchronization fixes this by forcing a cache flush or a write-through
when the mutex ends. You aren't just forcing exclusive access, you're
making sure the JVM knows the variable is used by multiple threads and
therefore need to be made visible to all threads each time you change it.

Volatile does this too, and so do the concurrent objects like
AtomicInteger.

 

[John B. Matthews]

To the OP: That link there talks about visibility, which is the other
issue. Synchronization does more in Java than just guarantee mutual
exclusion. It also manages where and when your variable(s) is visible
to other threads.

Imagine that you have, not just multiple threads, but multiple CPUs.
Each CPU has it's own cache internally. If you have one thread,
reading modifying and writing a variable it's possible that the
variable is only modified by the one CPU, and it's values never leave
the caches.

Synchronization fixes this by forcing a cache flush or a
write-through when the mutex ends. You aren't just forcing exclusive
access, you're making sure the JVM knows the variable is used by
multiple threads and therefore need to be made visible to all threads
each time you change it.

Volatile does this too, and so do the concurrent objects like
AtomicInteger.

OP: Mark, Matt, Lew, et al. have helpfully expanded on this issue. If I
may suggest one other link, the package summary for the current version
of java.util.concurrent has added a section called "Memory Consistency
Properties":

<http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html>

It nicely summarizes several of the key points about synchronization,
visibility and execution order.

 

[Daniel Pitts]

Let's say you have an integer called progress which represents a
thread's progress (from 0 to 100 percent).

A worker thread sets this progress variable.

Another thread reads the progress variable and simply displays it.

Is there any need for the synchronized keyword in writing this code?

Thanks.

In the form of using "volatile", yes.

Although, a better design would be to have your worker thread send a
message to the other thread (using queues, locks, or other synchronizing
primitives). Otherwise the other thread will be in a "spin loop", which
is generally a Bad Thing.