--- Thread Synchronization of Multithreading

Thread Synchronization

Keywords Java platform for coordination among threads shared data access: volatile, synchronized, final, static; mechanisms: lock; API: Object.wait () / Object.ntify ()

lock

Also known as mutex lock / exclusive lock is to control the original parallel threads access shared variable to serial access, each thread needs to access the variable that holds the lock, the lock can be seen as a license holder can access, logical thread to complete the operation (to acquire a lock code execution after it became critical section) will release the lock, the next thread to hold;

Problems caused by lock

• Cost: context switch

• Lock leak: Because the program error, the lock has been occupied by a thread, re-use, other threads can never hold

• Deadlock

Lock role

To protect shared variables to ensure the security thread, namely atomicity / Visibility / orderliness, but the need to ensure that all access the same critical section of code that use the same thread lock, even if only need to read the thread that holds the lock

• Atomicity

  By mutex lock to ensure atomicity, that only one thread can execute, other threads can not be bothered; if this thread quits unexpectedly (involuntary switch), then thread just do it there, you can guarantee atomicity

• Visibility

  When the writer thread will get an update lock shared variables do synchronized to cache the thread execution processor (ensure this thread to get a newer result); the lock is released, the writer thread of shared variables can be made to update pushed to the thread executed by the processor cache, so that the read thread synchronization (read newer results); atomicity guarantees providing visible thread holding the lock to read the shared variables (referenced type shared variable / array the results of each variable element) is the latest result

• Orderliness

  Because the results of atomicity and visibility of security, read the thread on the same thread write operation sequence of perception and source code; but it can not guarantee the critical area of ​​memory operations it will not be reordered because atomicity, this will not be reordered to other thread impact

Reentrancy

When a thread holding a lock, the lock is not released Shihai again successfully applied to the lock hold (how to achieve TODO)

Explicit locks and internal lock

• Internal lock

  implemented by the synchronized keyword, also known as a monitor, a non-fair locks

  • synchronized keyword, it locks the handle usually private finalmodified to prevent its tag value is changed, resulting in a plurality of threads of different locks, race conditions;

    Java virtual machine to perform on behalf of the application and release the internal locks, and the program has thrown an uncaught exception made special treatment, so the situation has not been released lock does not appear to circumvent the problem of leakage lock

    Internal lock scheduling and related Java virtual machine, it is assigned a set of entry for storing the corresponding thread waiting to acquire a lock for each internal lock, when the lock is occupied, threads within this set (application lock failure) are in pause blocked state and waiting for an opportunity to re-apply the lock, when the lock is released, the threads within this collection will be awakened, and the newly created thread to seize the lock is released together

    jdk1.6 / 1.7 several optimizations, such as locks elimination lock roughening biased lock, lock adaptability, reduces scalability TODO differences between the explicit lock

• Explicit lock

  Implemented by the Lock interface implementation class under jucl package, either for fair locks can also support non-arm lock (default)

  tryLock way to support application locks a short time, if not directly apply to return false

• Read-Write Lock

  Share / exclusive lock, a lock to play the role of other kinds of locks. Reading Lock: the corresponding write lock is not held by any thread that allows multiple threads simultaneously read read shared variables; write lock: Lock and read the corresponding write lock is not held by any other thread, with exclusive access to the shared variable

  Suitable for read-only operations frequently than write, read locks held longer

Memory barrier

Memory barriers prohibit compiler / processor reordering in order to ensure orderly, but there are two actions together to perform: Refresh processor cache and processor cache flush, the two movements is the basis of visibility guaranteed.

That if there is no visibility of demand or ordering requirements, how to do?