The semantics are that the write is guaranteed not to be re-ordered with any previous write, but may be reordered with subsequent operations (or equivalently, might not be visible to other threads) until some other volatile write or synchronizing action occurs).
那么U.putOrderedObject(a, j, task);
U.putOrderedInt(q, QTOP, s + 1);
U.putIntVolatile(q, QLOCK, 0);
这3条operations的顺序是order(1 -> 2 -> 3)的,那么可见性的顺序保证(3 -> 2 -> 1), 即3可见了, 2 一定可见, 2 可见了, 那么1一定可见。
(语言组织不严谨, 不过道理基本如此)
forkjoinpool代码逻辑太多, 不分析了, 可以看看futureTask
protected void set(V v) {
if (UNSAFE.compareAndSwapInt(this, stateOffset, NEW, COMPLETING)) {
outcome = v;
UNSAFE.putOrderedInt(this, stateOffset, NORMAL); // final state
finishCompletion();
}
}
/**
* @throws CancellationException {@inheritDoc}
*/
public V get() throws InterruptedException, ExecutionException {
int s = state;
if (s <= COMPLETING)
s = awaitDone(false, 0L);
return report(s);
}
注意: get时, 判断state <= COMPLETING(重点) 时, 要继续wait, 结合outcome = v; UNSAFE.putOrderedInt(this, stateOffset, NORMAL); 这两个operations, 那么state设置为NORMAL(NORMAL>COMPLETING)可见, 那么outcome = v时可见的