Link Details

"shared variables require special handling–they need synchronization. "

Wrong, at least, not if they are immutable.

"Because of the presence of shared state, a Thread object must be considered shared, thus requiring synchronization."

This is the false premise on which the following is based. Of course, Thread objects need not be synchronized which would defeat their purpose. What’s Wrong with the Thread Object? Nothing. Milewski nowadays dabbles in Java instead of C++ and D.

True: as long as your language supports immutable (D, Scala, but none of the most popular OO languages like Java, C++, and C#) and you restrict yourself to immutable variables you don't need synchronization (I talked about it in my previous blogs). But if I fully qualified every statement, my blog would be unreadable.

If a Thread object contains shared state it *must* be synchronized. The premise is correct.

Java fosters immutable value types. Almost all values (not objects) are immutable in Standard Java (with the notable exception of 'Date').

"If a Thread object contains shared state it *must* be synchronized."

Thread object per se need not and should not be synchronized. Access to "shared state" within a Thread object may be synchronized unless other conventions for state change take place (e.g. worker threads are not allowed to change the state). Usually objects shared between threads are not synchronized by the Thread object (that would be impossible for large object graphs) but provide 'internal' means for synchronized and atomic operations, see e.g. ConcurrentHashMap ( http://www.j2ee.me/javase/6/docs/api/java/util/concurrent/ConcurrentHashMap.html )

You are missing my point. Synchronization based on conventions rather than being enforced by the language is what makes multithreaded programming extremely hard.

That's true but isn't the point of you blog post. Anyway, if you are really interested in Java I recommend Goetz' ' Java Concurrency in Practice':
http://www.briangoetz.com/pubs.html


.