

Things You Didn’t Know About Synchronization in Java and Scala - heapster
http://www.takipiblog.com/2013/08/15/5-things-you-didnt-know-about-synchronization-in-java-and-scala/

======
yebyen
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."

~~~
ddeck
_> 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
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.

~~~
ddeck
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]
[http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html...](http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.4)

~~~
yebyen
This sounds more like what we experienced:

> The write of the default value (zero, false or null) to each variable
> synchronizes-with the first action in every thread. Although it may seem a
> little strange to write a default value to a variable before the object
> containing the variable is allocated, conceptually every object is created
> at the start of the program with its default initialized values.

I can't get that to jibe in my memory though against:

> The final action in a thread T1 synchronizes-with any action in another
> thread T2 that detects that T1 has terminated.

> T2 may accomplish this by calling T1.isAlive() or T1.join().

If we were looking into the threads, it would have been obvious that we should
wait for the thread to finish before expecting to find a completed value in it
other than the default. That's not what happened.

It's unfortunate that I didn't get a copy of the code in question, because it
was a genuine idiosyncrasy in Java and by the time I got around to asking my
friend for a copy, he had already rewritten his code in a different way that
didn't hit the same bug.

Didn't use revision control, got his degree didn't care to repeat the same
miserable exercises, now probably hacking ruby in his day job like me (except
I promise I'm using revision control.)

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

~~~
kasey_junk
Just remember under the covers Akka is still using synchronization.

~~~
asperous
You mean internally? The paradigm they use is immutable-message passing and
asynchronous/concurrent processing.

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

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

------
ExpiredLink
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
What do you mean you didn't know. I knew all that :)

