[dragontamer]

That's Java's Object.lock() mechanism.

All variables inside of an object (aka: any class) are assumed to be related to each other. synchronized(foobar_object){ baz(); } ensures that all uses of foobar_object inside the synchronization{} area are sequential (and therefore correct).

--------

The issue is that some people (a minority) are interested in "beating locks" and making something even more efficient.

[karmakaze]

In Java, any object can be used to synchronize any data, e.g.

  synchronized(foobar_object){ foo(); }
  synchronized(foobar_object){ bar(); }
  synchronized(foobar_object){ baz(); }

Will have foo, bar, baz methods well behaved in any data that they share regardless of whether they are foobar methods or methods of any other class(es). It is exactly analogous to the S(a) -> S(a) synchronizing instruction from the article that establishes a happens-before partitioning each thread into before/after the S(a).

The only time synchronized(explicit_object) relates to anything else is when also using the keyword where `synchronized void foo()` is equivalent (with a minor performance difference) to `synchronized(this) { ... }` wrapping the entire body of the foo method.

[pjmlp]

Although in highly parallel code, the primitives from java.util.concurrent are to be preferred.

I highly advise reading "Java Concurrency in Practice".

Note that future Java primitive classes don't have monitors.

[karmakaze]

Seems like a vague way of saying that locks 'don't scale' or aren't composable, which is certainly the case but straying from the topic of memory models.