Java.util.Locale not thread-safe !

Question

In multithreading programming, we know that double-checking idiom is broken. But lots of code, even in sun java core libraries, are written using this idiom, like the class "java.util.Locale".
I have submitted this bug report just now,
but I wanted to have your opinion about this.
Don't you think a complete review of the source code of the core libraries is necessary ?
java.util.Locale seems not to be thread safe, as I look at the source code.
The static method getDefault() is not synchronized.
The code is as follows:
public static Locale getDefault() {
// do not synchronize this method - see 4071298
// it's OK if more than one default locale happens to be created
if (defaultLocale == null) {
// ... do something ...
defaultLocale = new Locale(language, country, variant);
return defaultLocale;
This method seems to have been synchronized in the past, but the bug report 4071298 removed the "synchronized" modifier.
The problem is that for multiprocessor machines, each processor having its own cache, the data in these caches are never synchronized with the main memory.
The lack of a memory barrier, that is provided normally by the "synchronized" modifier, can make a thread read an incompletely initialized Locale instance referenced by the static private variable "defaultlocale".
This problem is well explained in http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html and other documents about multithreading.
I think this method must just be synchronized again.

Answer 1

Shankar, I understand that this is something books and articles about multithreading don't talk much about, because for marketing reasons, multithreading is supposed to be very simple.
It absolutely not the case.
Multithreading IS a most difficult topic.
First, you must be aware that each processor has its own high-speed cache memory, much faster than the main memory.
This cache is made of a mixture of registers and L1/L2/L3 caches.
Suppose we have a program with a shared variable "public static int a = 0;".
On a multiprocessor system, suppose that a thread TA running on processor P1 assign a value to this variable "a=33;".
The write is done to the cache of P1, but not in the main memory.
Now, a second thread TB running on processor P2 reads this variable with "System.out.prinln(a);".
The value of "a" is retrieved from main memory, and is 0 !
The value 33 is in the cache of P1, not in main memory where its value is still 0, because the cache of P1 has not been flushed.
When you are using BufferedOutputStream, you use the "flush()" method to flush the buffer, and the "synch()" method to commit data to disk.
With memory, it is the same thing.
The java "synchronized" keyword is not only a streetlight to regulate traffic, it is also a "memory barrier".
The opening brace "{" of a synchronized block writes the data of the processor cache into the main memory.
Then, the cache is emptied, so that stale values of other data don't remain here.
Inside the "synchronized" block, the thread must thus retrieve fresh values from main memory.
At the closing brace "}", data in the processor cache is written to main memory.
The word "synchronized" has the same meaning as the "sync()" method of FileDescriptor class, which writes data physically to disk.
You see, it is really a cache communication problem, and the synchronized blocks allows us to devise a kind of data transfer protocol between main memory and the multiple processor local caches.
The hardware does not do this memory reconciliation for you. You must do it yourself using "synchronized" block.
Besides, inside a synchronized block, the processor ( or compiler ) feels free to write data in any order it feels most appropriate.
It can thus reorder assignments and instruction.
It is like the elevator algorithm used when you store data into a hard disk.
Writes are reordered so that they can be retrieved more efficiently by one sweep or the magnetic head.
This reordering, as well as the arbitrary moment the processor decides to reconciliate parts of its cache to main memory ( if you don't use synchronized ) are the source of the problem.
A thread TB on processor P2 can retrieve a non-null pointer, and retrieve this object from main memory, where it is not yet initialized.
It has been initialized in the cache of P1 by TA, though, but TB doen't see it.
To summarize, use "synchronized" every time you access to shared variables.
There is no other way to be safe.
You get the problem, now ?
( Note that this problem has strictly nothing to do with the atomicity issue, but most people tend to mix the two topics...
Besides, as each access to a shared variable must be done inside a synchronized block, the issue of atomicity is not important at all.
Why would you care about atomicity if you can get a stale value ?
The only case where atomicity is important is when multiple threads access a single shared variable not in synchronized block. In this case, the variable must be declared volatile, which in theory synchronizes main and cache memory, and make even long and double atomic, but as it is broken in lots of implementation, ... )