Live data from Hacker News

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

takipiblog.com

1–10 of 24 posts

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

#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

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

#3
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?

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

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

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

#5
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…

Indeed, one of Java's most arcane features. A good related SO thread:

http://stackoverflow.com/questions/16159203/why-does-this-ja...

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

#7

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

Clojure's STM is also an interesting model.

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

#8

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

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

#9
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?

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.

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

#10

> 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 single threaded than not in my opinion.

Post reply on HN