

Things you didn't know about multithreaded programming - fogus
http://www.ibm.com/developerworks/java/library/j-5things15/index.html?ca=drs-

======
lemming
This is a pretty crappy article in my opinion, and certainly won't do anything
to help the problem that the author describes - that developers' knowledge of
concurrency comes piecemeal without any structure.

I challenge anyone to gain an understanding of volatile variables from his
description. His example of volatile vs. synchronised contains an example of
incorrect code but not an example of how it should be fixed, and doesn't even
contain a particularly clear explanation of why it's bad.

The explanation of the bytecode generated for a synchronised method compared
to a synchronised block is curious if you're into bytecode but totally useless
for a working programmer, and offers no guidance on choosing between them.
Worse, it actually makes it sound like the option you almost certainly don't
want (the synchronised method) is somehow more efficient than the almost
universally better method (synchronising on a lock object, which provides much
better lock granularity, prevents deadlock in the case of some external object
claiming your object lock and generally makes lock ownership much clearer and
easier to track).

Finally, his example of the AtomicReferenceFieldUpdater ignores the javadoc (
_This class is designed for use in atomic data structures in which several
reference fields of the same node are independently subject to atomic updates_
) and proceeds to show a contrived example of a compareAndSet that is really
only a more confusing set, and doesn't actually achieve anything at all.

There are much better sources to learn this stuff if you really need to know
it, starting with Java Concurrency In Practice - no Java programmer should be
writing concurrent code without having read the first 7 chapters of this.

~~~
motxilo
Agreed. It's hard to discern the real value of using synchronized methods vs
synchronized blocks when you end up reading: "Creating the synchronized block
yielded 16 lines of bytecode, whereas synchronizing the method returned just
5". As you point out, synchronization on a lock object is, as a rule of thumb,
a much better option than synchronizing on the intrinsic lock, and thus losing
control over it.

The explanation of volatile is woeful, to say the least. He doesn't even
mention the main issue that volatile addresses (the only one?): visibility.
Anyone really interested in this should read the following article by the
author of JCIP:
[http://www.ibm.com/developerworks/java/library/j-jtp06197.ht...](http://www.ibm.com/developerworks/java/library/j-jtp06197.html)

I liked the section regarding ThreadLocal though (an example would've helped a
bit).

------
Jabbles
...in Java. Or at least, the JVM.

Does anyone know the limits of the JVM for multithreading? e.g. Max number of
cores

~~~
mzl
Any limits depend on the particular JVM that you are using. In practice one
needs to experiment.

A few years back I did some comparisons between Java and Erlang with respect
to the number of threads the system could handle. Somewhere around a thousand
threads was sufficient to make the JVM go very slowly.

~~~
lemming
See Kilim (<http://www.malhar.net/sriram/kilim>) for a lightweight thread
solution for Java that easily outpaces Erlang for thread creation and message
passing. It's the basis for the Erjang project which runs Erlang bytecode on
the JVM. While it's faster at a low level, it obviously doesn't provide
everything that Erlang does (supervisor hierarchies etc). It's still pretty
impressive that this can be achieved on the JVM though.

~~~
silentbicycle
Well, sure. Erlang processes aren't threads. They're more like pre-empted
coroutines, with a scheduler that factors in when they're blocking and waiting
to receive a message (among many other things).

~~~
mzl
What would you say the essential difference is betwee pre-empted coroutines
with a scheduler and threads?

The only thing I could think of is that with coroutines one can explicitly
pass control over to another coroutine, but that is something that Erlang does
not provide, so I don't really understand what you mean.

~~~
silentbicycle
Erlang processes are managed by its scheduler, while threads are managed by
the OS. Erlang has more info about appropriate stack sizes, garbage collection
is done per-process* , it only pre-empts processes that are currently working
or recently got a new message, and probably a half dozen other optimizations
I'm not aware of. Let me know if you have more questions, I really like Erlang
and I've wanted an excuse to research this. :)

* And often doesn't need to be done at all, because the process terminates first.

------
larsberg
For people actually interested in parallel programming, particularly on Java,
Herlihy's _The Art of Multiprocessor Programming_ is a fantastic introduction.
On top of the grab-bag of techniques you'd expect, it boasts enough formal
treatment to help folks learn to reason about correctness in their own
programs.

------
rbranson
This article should be renamed to "beginners guide to multithreaded
programming in Java."

------
jbarham
Articles like this make me appreciate Go's approach to concurrency
(<http://golang.org/doc/effective_go.html#concurrency>).

------
ddlatham
Synchronized methods and blocks generate different bytecode, but according to
the spec, have "exactly the same effect".

[http://java.sun.com/docs/books/jls/third_edition/html/classe...](http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.4.3.6)

[http://stackoverflow.com/questions/417285/equivalent-code-
fo...](http://stackoverflow.com/questions/417285/equivalent-code-for-instance-
method-synchronization-in-java/417382#417382)

------
CodeMage
The only part I found interesting was the first part, but only because it
raises an interesting question that the author (unfortunately) didn't address:

Supposing you want to synchronize only one part of your method, which approach
would cause the JVM to do less work: putting that part in a synchronized block
(thus generating extra bytecode instructions) or extracting it into a
synchronized method (thus generating an additional call)?

Not that it's really important -- micro-optimizations like that are silly --
but it does make me curious.

~~~
drblast
The article really fails here, this is a horrible example and horrible
reasoning.

I'm no Java expert, but the reason you'd synchronize a smaller block of code,
or use any finer grain lock, rather than a whole method is that you'd have a
shorter time to wait if many threads are competing for the lock. You'd
increase utilization.

Lines of bytecode doesn't really tell you anything, especially since the
synchronized method is a stub that does nothing. Not only that, but the
synchronized method does all its synchronization work implicitly; the JVM
still has to acquire the lock somehow, it's just not written in the bytecode.

What really matter is what happens when the bytecode is compiled to native
code, so you could see the synchronized method call overhead. If the article
analyzed _that_ , it would be helpful.

------
barfoomoo
Reference field update operations in Java are not thread safe?

~~~
jbellis
reference updates are atomic, but without volatile (or more heavyweight
synchronization) there may be an arbitrary delay before the change is visible
to other threads.

~~~
barfoomoo
Thanks for that.

------
known
Kernel locking <http://www.linuxjournal.com/article/5833>

