Java concurrent: ReentrantLock - wrong design?

I know that ReentrantLock uses AbstractQueuedSynchronizer ( AQS ) to implement Locking . But the implementation details, I cannot figure out.

I know AQS uses volatile, CAS and works for synchronization. But these actions only control the "state" member.

Although LockSupport.park and LockSupport.unpark can synchronize the stream cache. But if there is never a dispute, the LockSupport methods will never be called. Like this: 1.Thread Start and Start

2. Run and run Run B

3.Thread A:

lock.lock();
try{
  //modify some shared members
  ....
}finally{
  lock.unlock();
}

      

4. Then Thread B:

lock.lock();
try{
  //read shared members
  ....
}finally{
  lock.unlock();
}

      

No contention , thread B does not call LockSupport methods .

lock.lock () only CAS "state" and lock.unlock () changes the changed state "to 0.

Why can thread B see thread A change about shared members?

Why can ReentrantLock be used as "synchronized"?

I haven't seen any code like fullFence to sync memory.

What code implements stream cache synchronization?

Thank!

+3


source to share


1 answer


CAS operations define an event - before a relationship, so the Java memory model ensures that memory changes from a thread are visible from another.



0


source







All Articles