Question

I am reading Java Concurrency in Practice

I am confused with the specific explanation regarding happens-before relationship.

It states that,

operations are ordered by a partial ordering called happens-before

What exactly does this mean by "partial ordering"?

(There is an explanation in the book but its not clear to me )

Was it helpful?

Solution

Partial Ordering means that not every pair of operations has the relation happens-before.

Actually, the fact that not every pair of operations has that relation enables you to perform operations concurrently.

For example, suppose you have operations A, B, C & D.

We can define a partial ordering: A must happen before B and C.

Then A and B have the happens-before relation, as do A and C. However, A and D don't have that relation, so D can be executed either before A, after A or while A is being executed.

If, on the other hand, happens-before was a full ordering, such as A happens-before B happens-before C happens-before D (note that in this case, for each pair of operations you know which one happens-before the other, hence it is a full ordering), then the execution of the operations would have to be serial, and no concurrency would be possible.

OTHER TIPS

Since you are referring to the book “Java Concurrency in Practice” I suppose you are at the part about the Java Memory Model.

It seems natural to a programmer that the CPU executes the program’s statements in the order as they appear in the source code with respect to the control flow. But several factors like optimizing compilers, CPU architectures, etc. impose a different low-level behavior. This, however, is not visible to the thread executing the code. It will behave as if everything happens in order.

This does not hold true for multiple threads anymore. Threads may observe a different order of the actions of another thread when no happens before relationship exist. So for these actions no specified ordering relationship exist. E.g. when a thread executes the code

static Point XY;
…
XY = new Point(3, 4);

another Thread might observe the storage of the Point instance into the XY field before the initialization of the x and y fields of that instance thus seeing a (0,0) or (3,0) or (0,4) point.

So no ordering relationship between the actions “assignment of XY”, “assignment of x”, and “assignment of y” and reading these variables exists.

If we change the variable declaration XY to volatile, a happens-before relationship between storing the Point instance into XY and reading that instance reference is established. Still, there’s no ordering between the writes of x and y but now both writes have a happens-before relationship to the reading of these two field through XY.

So that’s the partial ordering; some actions have an ordering relationship, others have not.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top