So che ReentrantLock utilizzare AbstractQueuedSynchronizer ( AQS ) per implementare Blocca . Ma il dettaglio della realizzazione, non riesco a capire.
So che AQS usa volatile, CAS e gira per la sincronizzazione. Ma queste azioni controllano solo il membro "stato".
Sebbene LockSupport.park e LockSupport.unpark possano sincronizzare la linea del thread. Ma se non ci sono mai contese, i metodi LockSupport non verranno mai chiamati. Come questo: 1.Thread A start ed esegui
2.Thread B inizia ed esegue
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();
}
Nessuna contesa, il thread B non chiama i metodi LockSupport .
lock.lock () solo CAS membro "stato" e lock.unlock () modifica lo "stato" volatile su 0 .
Perché il thread B può vedere la modifica del thread A sui membri condivisi?
Perché ReentrantLock può essere utilizzato come "sincronizzato"?
Non ho visto alcun codice come fullFence per sincronizzare la memoria.
Quale codice realizza la sincronizzazione della cacheline del thread?
Ho visto il codice sorgente in Android art vm e HotSpot vm.
In Android:
Utilizza std :: atomic - > compare_exchange_strong e Heap :: WriteBarrierField. Questi funziona come solo modificare un campo, non tutte le linee di caching di un thread.
In HotSpot:
Utilizza Atomic :: cmpxchg_ptr (il suo codice asm modifica un campo) e update_barrier_set. Queste funzioni, inoltre, come solo modificare un campo, non aggiornare tutte le linee di caching di un thread.
Mi fraintendono?