Java LockSupport Memory Consistency

Java 6 API question. Does calling LockSupport.unpark(thread) have a happens-before relationship to t开发者_如何学编程he return from LockSupport.park in the just-unparked thread? I strongly suspect the answer is yes, but the Javadoc doesn't seem to mention it explicitly.

I have just found this question because I was asking myself the same thing. According to this article by Oracle researcher David Dice, the answer seems to be no. Here's the relevant part of the article:

If a thread is blocked in park() we're guaranteed that a subsequent unpark() will make it ready. A perfectly legal but low-quality implementation of park() and unpark() would be empty methods, in which the program degenerates to simple spinning. An in fact that's the litmus test for correct park()-unpark() usage.

Empty park() and unpark() methods do not give you any happens-before relationship guarantees, so for your program to be 100% portable, you should not rely on them.

Then again, the Javadoc of LockSupport says:

These methods are designed to be used as tools for creating higher-level synchronization utilities, and are not in themselves useful for most concurrency control applications. The park method is designed for use only in constructions of the form:

while (!canProceed()) { ... LockSupport.park(this); }

Since you have to explicitly check some condition anyway, which will either involve volatile or properly synchronized variables, the weak guarantees of park() should not actually be problem, right?

If it isn't documented as such then you CANNOT rely on it creating a happens before relationship.

Specifically LockSupport.java in Hotspot code simply calls Unsafe.park and .unpark!

The happens-before relationship will generally come from a write-read pair on a volatile status flag or something similar.

Remember, if it isn't documented as creating a happens-before relationship then you must treat it as though it does not even if you can prove that it does on your specific system. Future systems and implementations may not. They left themselves that freedom for good reason.

I have looked though the JDK code and it looks like LockSupport methods are normally called outside of synchronization blocks. So, your assumption seems to be correct.