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

Post by kasey_junk » Thu, Aug 15, 2013, 1:36 PM UTC

benjaminwootton wrote: post #10

kailuowang wrote: post #6

> 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.

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…

Post by yebyen » Thu, Aug 15, 2013, 2:03 PM UTC

ddeck wrote: post #12

yebyen wrote: post #4

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…

>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 curr…

Post by yebyen » Thu, Aug 15, 2013, 2:33 PM UTC

ddeck wrote: post #14

yebyen wrote: post #13

Earlier quoted context omitted.

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 lo…

The implicit synchronization happens at the point the child thread is started, regardless of when it was allocated. Perhaps it was already started prior to the initialization, in which case some form of explicit synchronization would be required to ensure visibility. FYI, the relevant section of the JLS is 17.4.4: "An action that starts a thread synchronizes-with the first action in the thread it starts." [1]. [1] ht…

Post by gtani » Thu, Aug 15, 2013, 4:45 PM UTC

jedimouse wrote: post #3

skyebook wrote: post #2

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

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?

Post by asperous » Thu, Aug 15, 2013, 6:00 PM UTC

kasey_junk wrote: post #8

kailuowang wrote: post #6

> 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.

Just remember under the covers Akka is still using synchronization.