title: Does the synchronized construct in Java use internally (and somehow) the hardware primitive CAS operation?
body: <p>I am having a hard time understanding what is the <strong>hardware support</strong> for the <code>synchronized</code> statement and associated <code>notify()</code>, <code>notifyAll()</code> and <code>wait()</code> methods, present on every java object.</p>
  
  <p>I have read and know how to use this constructs but I have always assumed that they were mapped directly to hardware primitives.</p>
  
  <p>As I delve further on books about concurrency, I only read about the compare-and-swap (CAS) operation being directly provided by hardware.  </p>
  
  <p>It seems as though this constructs are created/maintained by the JVM itself. If my reading is correct, each object contains <strong>some state</strong> with information about the thread accessing it. This being used to define the monitor of that object and coordinate the access for multiple threads to that object.<br>
  But if that is the case, how <strong>is this state itself managed from concurrent access</strong> ? It must surely be managed, correct ? Is it with CAS ?  </p>
  
  <p>If it is with CAS, that means there is only one real form of synchronization, CAS. All others being derivatives. Why then was this monitor construct with the associated <code>synchronized</code>, <code>notify()</code>, <code>notifyAll()</code>, <code>wait()</code> methods developed given that the <strong>Atomic</strong> variables (i.e. CAS) are better in terms of performance and also wait-free ? </p>
  
  <p>I am aware that <strong>Atomic</strong> variables to user classes appeared only after Java 5.0 or so, but before that Java already this monitors/intrinsic locks. How were they implemented ?</p>