java synchronization gone wild and back

[juan_gandhi]

Hey, so, you, like everyone else, decided to make your static initialization thread-safe. You have a singleton that is hard to instantiate, and You have something like this:

static My worker;

static My worker() {
  if (worker == null) {
    worker = new MyImplementation();
  }
  return worker;
}

and it does not work, because, say, a dozen of servlet threads in parallel are trying to reinitialize your singleton like crazy; a minute that it takes to instantiate one, turns into 12 minutes, since all 12 are trying to do the same.

Okay, you synchronize it:

static My worker;

static synchronized worker() {
  if (worker == null) {
    worker = new MyImplementation();
  }
  return worker;
}

In this case you lock execution on the whole class; your class may have a bunch of other singletons, and they will all stand in line waiting for this specific singleton to be retrieved - looks stupid, right? so you introduce a gentle check:

static My worker;

static worker() {
  if (worker == null) {
    synchronized {
      worker = new MyImplementation();
    }
  }
  return worker;
}

See, before instantiating, you check whether it is instantiated already.

The trouble is, your twelve threads will get through this check and wait on the same barrier before synchronized block, and then will instantiate the singleton, one after another, taking 12 minutes in total. Okay, you get angry, you open a book and steal a solution, the famous double-check trick:

static My worker;

static worker() {
  if (worker == null) {
    synchronized {
      if (worker == null) {
        worker = new MyImplementation();
      }
    }
  }
  return worker;
}

Now you feel good, the threads would not reinitialize the same singleton, because when the second threads penetrates the synchronized block, worker is already not null. You feel good... but then you open Josh and Neal's Java Puzzlers, and see that oops, this won't work on a multiprocessor machine. Why? See, by the time the first thread leaves the syncrhonized block, the value of worker may not reach the memory shared by the threads.

So, the solution suggested is this:

static My worker;
private interface HR {
  My getWorker();
}

private static HR catbert = new HR() {
  My worker = new MyImplementation();
  My getWorker() {
    return worker;
  }
}

static worker() {
  return catbert.getWorker();
}

See, the trick is that the singleton is provided by a static class, which is loaded strictly once, which is guaranteed by the class loader.

Now enters "new Java 5", not sure which one, 1.5.0.6 or 1.5.0.7. Bug fixed. All you have to do is declare My worker volatile:

volatile static My worker;

static worker() {
  if (worker == null) {
    synchronized {
      if (worker == null) {
        worker = new MyImplementation();
      }
    }
  }
  return worker;
}

So, now we are back to circle 3: after a bugfix, double checks are legal again.

Comments

[itman.livejournal.com]

Любопытно, с phtread_mutex'ами проделывать подобные операции всегда

безопасно.
(http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpthread/pthread_mutex.c?rev=1.27&content-type=text/x-cvsweb-markup)
/*
* Note regarding memory visibility: Pthreads has rules about memory
* visibility and mutexes. Very roughly: Memory a thread can see when
* it unlocks a mutex can be seen by another thread that locks the
* same mutex.
*
* A memory barrier after a lock and before an unlock will provide
* this behavior. This code relies on pthread__simple_lock_try() to issue
* a barrier after obtaining a lock, and on pthread__simple_unlock() to
* issue a barrier before releasing a lock.
*/

Неужели synchronized в Java работает по-другому? Вот, например, в статье в Java World за 2001ый год Алан Голуб пишет буквально следующее:
"Memory barriers surround synchronization To summarize, synchronization implies a memory barrier. In that case, two exist: one barrier associated with entering a synchronized block or method and another associated with leaving it"
Неужели "гонит"?

[itman.livejournal.com]

пардон, вот сама статья (http://www.roseindia.net/software-tutorials/detail/2715)

[ivan-gandhi.livejournal.com]

Эта теория многих сбивала с толку, в том числе и меня. Хотелось бы, конечно, выслушать аргументы, почему оно не работает, но скорее всего именно поэтому, что надоест синхронизировать на каждый чих, особенно если процессоров много.

[itman.livejournal.com]

Как я там уже где-то писал в комментариях, теория не работает потому, что нужно выставлять барьер между инициализацией класса и "публикацией" ссылки класса "наружу". Потому что, де факто инициализация может случиться позже присваивания. Из-за пресловутого operation reordering. И тогда первый тред, который еще не зашел в синхронизированный блок, может увидеть не NULL ссылку на недостроенный объект и начать работать с ним. В плюсах будет точно такая же фигня.
Volatile в java, насколько я понимаю, делает этот самый memory barrier на кажду операцию доступа к volatile переменной. Таким образом, проверка
if (worker == NULL)
вне synchronized перестает, наверное, "облегченной". Вот тут, например, (http://blogs.msdn.com/brada/archive/2004/05/12/130935.aspx) говорят, что лучше не использовать volatile, а явным образом использовать memory barrier. В частности, это всегда корректно даже при отложенной инициализации.