Non-thread safe System.console(), although synchronized used?

Question

Hi, I recently noticed that the System.console() code looks like the following:
public static Console console() {
         if (cons == null) {
             synchronized (System.class) {
                 cons = sun.misc.SharedSecrets.getJavaIOAccess().console();
         return cons;
     }Is this thread safe, despite the synchronized block? I mean, suppose two threads try to get the console, and they both go past the null check. Then, one of them gets the lock, initializes the field blah blah. Then, the second gets the chance to run, and since it is past the null check, it will enter the synchronized code again. I don't know what happens in the sun.misc package, but as far as this code is concerned, this doesn't look valid to me. I might be wrong though :-)
Cheers.

Answer 1

DeltaGeek wrote:
Correct, that is not thread-safe. Why not just make the entire method synchronized?Because if cons is already non-null, there's no need to synchronize (assuming cons is the same object for each thread, something not evident in the code snippet...)
I'd put forth this:
public static Console console() {
         if ( null == cons ) {
             synchronized (System.class) {
                 // need second check in case cons was set while the thread
                 // was blocked
                 if ( null == cons ) {
                     cons = sun.misc.SharedSecrets.getJavaIOAccess().console();
         return cons;
     }And yes, I always put the non-L-value first, just in case I make a typo like this:
int x;
if ( x |= SOME_CONSTANT ) ...