5 ms·

Things You Didn’t Know About Synchronization in Java and Scala

54 points by heapster 13y ago

skyebook 13y ago
If this is interesting to you then I'd highly recommend Java Concurrency in Practice [1]. It goes through the then-new java.util.concurrent package, but more importantly, does a really good job of making all of the theoretical concepts straightforward to grasp 1 - http://www.amazon.com/gp/aw/d/0321349601 http://www.amazon.com/gp/aw/d/0321349601
- jedimouse 13y ago
  Great book indeed. Along with effective Java, its one of my alltime favorites. But since its a Java book, it doesnt if I recall correctly detail how things are implemented at the core JVM level. Does anyone know a good book or source about that?
  - kasey_junk 13y ago
    It depends on the JVM you are using. If it is an open source one you can look yourself. A little old but Oracle JRockit: The Definitive Guide is a pretty good book on the JRockit JVM.
  - gtani 13y ago
    this was good http://www.artima.com/insidejvm/ed2/threadsynch3.html http://www.artima.com/insidejvm/ed2/threadsynch3.html
- bruceboughton 13y ago
  I've been searching for a book like this for .NET and the CLR to no avail. Can anyone recommend one? Or is this book applicable beyond Java?
  - cokernel_hacker 13y ago
    Concurrent Programming on Windows by Joe Duffy http://www.amazon.com/exec/obidos/ASIN/032143482X/bluebytesoftw-20 http://www.amazon.com/exec/obidos/ASIN/032143482X/bluebyteso...
    - bruceboughton 13y ago
      Thanks. I will take a look.
yebyen 13y ago
My favorite (having not read the post but just gone through CS undergrad in Java about four times by weight) was the mandatory locking in multithreaded programs in Java -- you can have parent threads and child threads, and you can set variables in your parent threads before the child threads execute, but unless you're doing it in a locking way (eg. with a shared semaphore) there's no guarantee that the parent thread actually executes before the child thread. That was a fun one to explain in office hours. "No no, it's not enough to just put this before that, you have to establish a Happens-Before relationship."
- nivstein 13y ago
  Indeed, one of Java's most arcane features. A good related SO thread: http://stackoverflow.com/questions/16159203/why-does-this-java-program-terminate-despite-that-appears-that-it-shouldt-and http://stackoverflow.com/questions/16159203/why-does-this-ja...
- ddeck 13y ago
  >you can set variables in your parent threads before the child threads execute, but unless you're doing it in a locking way (eg. with a shared semaphore) there's no guarantee that the parent thread actually executes before the child thread There are definitely some surprising outcomes from the JMM, but I'm pretty sure this isn't one of them. If I recall correctly, starting a thread automatically synchronizes the current thread with the first thing the child thread does, without any explicit synchronization. So anything done prior to that point in the parent thread will be visible in the child.
  - yebyen 13y ago
    I do not have the code here to show you, but if I am exaggerating it's a small fib. Maybe the child thread was created some time before it was started, and the initialization happened some time between those events. It was an example that a friend was working for a class, and as they often do, came to me for help on why it wasn't behaving as expected. I looked at it and I could see the problem, "you don't have any locks shared between parent and child." We added a lock, synchronized it once in each thread, and the problem went away. That's definitely a surprising outcome for anyone who is accustomed to procedural programming.
kailuowang 13y ago
> Practically all server applications require some sort of synchronization between multiple threads. It could be just me but I think the author should've mentioned alternative concurrent programming models available for JVM such as Akka.
- AndreasFrom 13y ago
  Clojure's STM is also an interesting model.
- kasey_junk 13y ago
  Just remember under the covers Akka is still using synchronization.
  - asperous 13y ago
    You mean internally? The paradigm they use is immutable-message passing and asynchronous/concurrent processing.
    - kasey_junk 13y ago
      Yes internally. Somewhere deep in the bowels of the akka code, they are communicating state between threads (last I checked they were using a java concurrent queue by default). At a bare minimum the changes to the location of the head/tail of a queue will need to be visible to multiple threads requiring volatile variables. The java concurrent queues don't actually use synchronization blocks, they use native CAS operations but thinking that akka removes shared thread state entirely is dangerous.
- benjaminwootton 13y ago
  Even lots of low latency standard Java is tending towards single threaded non blocking models without synchronisation. The costs of synchronised blocks is high on the JVM. They defer to the operating system for thread scheduling, they enforce a memory barrier meaning all data is flushed out to RAM rather than CPU caches, and multithreaded code dirties CPU caches, reducing performance. More server side code should be single threaded than not in my opinion.
ExpiredLink 13y ago
Fact #0. If you write 'synchronized' in Java code you are doing it wrong. Seriously. 'synchronized' indicates that the programmer is re-inventing and/or re-implementing a solved problem. In Java parallelism and concurrency for most real-wold problems are handled by frameworks or covered by well-known patterns.
abc_lisper 13y ago
What do you mean you didn't know. I knew all that :)

54 points by heapster 13y ago

If this is interesting to you then I'd highly recommend Java Concurrency in Practice [1]. It goes through the then-new java.util.concurrent package, but more importantly, does a really good job of making all of the theoretical concepts straightforward to grasp 1 - http://www.amazon.com/gp/aw/d/0321349601 http://www.amazon.com/gp/aw/d/0321349601

jedimouse 13y ago
Great book indeed. Along with effective Java, its one of my alltime favorites. But since its a Java book, it doesnt if I recall correctly detail how things are implemented at the core JVM level. Does anyone know a good book or source about that?
- kasey_junk 13y ago
  It depends on the JVM you are using. If it is an open source one you can look yourself. A little old but Oracle JRockit: The Definitive Guide is a pretty good book on the JRockit JVM.
- gtani 13y ago
  this was good http://www.artima.com/insidejvm/ed2/threadsynch3.html http://www.artima.com/insidejvm/ed2/threadsynch3.html
bruceboughton 13y ago
I've been searching for a book like this for .NET and the CLR to no avail. Can anyone recommend one? Or is this book applicable beyond Java?
- cokernel_hacker 13y ago
  Concurrent Programming on Windows by Joe Duffy http://www.amazon.com/exec/obidos/ASIN/032143482X/bluebytesoftw-20 http://www.amazon.com/exec/obidos/ASIN/032143482X/bluebyteso...
  - bruceboughton 13y ago
    Thanks. I will take a look.

yebyen 13y ago

My favorite (having not read the post but just gone through CS undergrad in Java about four times by weight) was the mandatory locking in multithreaded programs in Java -- you can have parent threads and child threads, and you can set variables in your parent threads before the child threads execute, but unless you're doing it in a locking way (eg. with a shared semaphore) there's no guarantee that the parent thread actually executes before the child thread. That was a fun one to explain in office hours. "No no, it's not enough to just put this before that, you have to establish a Happens-Before relationship."

nivstein 13y ago
Indeed, one of Java's most arcane features. A good related SO thread: http://stackoverflow.com/questions/16159203/why-does-this-java-program-terminate-despite-that-appears-that-it-shouldt-and http://stackoverflow.com/questions/16159203/why-does-this-ja...
ddeck 13y ago
>you can set variables in your parent threads before the child threads execute, but unless you're doing it in a locking way (eg. with a shared semaphore) there's no guarantee that the parent thread actually executes before the child thread There are definitely some surprising outcomes from the JMM, but I'm pretty sure this isn't one of them. If I recall correctly, starting a thread automatically synchronizes the current thread with the first thing the child thread does, without any explicit synchronization. So anything done prior to that point in the parent thread will be visible in the child.
- yebyen 13y ago
  I do not have the code here to show you, but if I am exaggerating it's a small fib. Maybe the child thread was created some time before it was started, and the initialization happened some time between those events. It was an example that a friend was working for a class, and as they often do, came to me for help on why it wasn't behaving as expected. I looked at it and I could see the problem, "you don't have any locks shared between parent and child." We added a lock, synchronized it once in each thread, and the problem went away. That's definitely a surprising outcome for anyone who is accustomed to procedural programming.

kailuowang 13y ago

> Practically all server applications require some sort of synchronization between multiple threads. It could be just me but I think the author should've mentioned alternative concurrent programming models available for JVM such as Akka.

AndreasFrom 13y ago
Clojure's STM is also an interesting model.
kasey_junk 13y ago
Just remember under the covers Akka is still using synchronization.
- asperous 13y ago
  You mean internally? The paradigm they use is immutable-message passing and asynchronous/concurrent processing.
  - kasey_junk 13y ago
    Yes internally. Somewhere deep in the bowels of the akka code, they are communicating state between threads (last I checked they were using a java concurrent queue by default). At a bare minimum the changes to the location of the head/tail of a queue will need to be visible to multiple threads requiring volatile variables. The java concurrent queues don't actually use synchronization blocks, they use native CAS operations but thinking that akka removes shared thread state entirely is dangerous.
benjaminwootton 13y ago
Even lots of low latency standard Java is tending towards single threaded non blocking models without synchronisation. The costs of synchronised blocks is high on the JVM. They defer to the operating system for thread scheduling, they enforce a memory barrier meaning all data is flushed out to RAM rather than CPU caches, and multithreaded code dirties CPU caches, reducing performance. More server side code should be single threaded than not in my opinion.

ExpiredLink 13y ago

Fact #0. If you write 'synchronized' in Java code you are doing it wrong. Seriously. 'synchronized' indicates that the programmer is re-inventing and/or re-implementing a solved problem. In Java parallelism and concurrency for most real-wold problems are handled by frameworks or covered by well-known patterns.

abc_lisper 13y ago

What do you mean you didn't know. I knew all that :)