Cert Obj Atomic Variables and Locks
Quiz yourself by thinking what should be in
each of the black spaces below before clicking
on it to display the answer.
Help!
|
|
||||
|---|---|---|---|---|---|
| [11.2.1] Certification Objective (Apply atomic variables and locks.) | Use Lock, ReadWriteLock, and ReentrantLock classes in the java.util.concurrent.locks package to support lock-free thread-safe programming on single variables.
🗑
|
||||
| [11.2.2] java.util.concurrent.atomic | package enables multithreaded applications to safely access
individual variables without locking,
🗑
|
||||
| [11.2.3] the java.util.concurrent.locks | package provides a locking framework that can be used to create locking behaviors
that are the same or superior to those of Java's synchronized keyword.
🗑
|
||||
| [11.2.4] beware of Java code such as counter++ | count++ statement will be translated to native CPU instructions and whether it ends up as a single instruction or several? You should always act as if a single line of Java code takes multiple steps to complete.
🗑
|
||||
| [11.2.5] java.util.concurrent.atomic package benefit | avoid making this code thread-safe with synchronized blocks, by provide variables whose values can be modified atomically.
🗑
|
||||
| [11.2.6] new classes in java.util.concurrent.atomic | AtomicInteger, AtomicLong, AtomicBoolean, and
AtomicReference,
🗑
|
||||
| [11.2.7] how do the Atomic classes work? | CAS stands for Compare And Swap.(getAndIncrement()) The central method in a class like AtomicInteger is the boolean
compareAndSet(int expect, int update) method, which provides the CAS behavior.
🗑
|
||||
| [11.2.8] java.util.concurrent.locks reason to use(one method to get a character's wealth, another method to perform gold transfers) | never check character's total wealth during gold transfer. Single method to get a character's total wealth;don't want thread to read the backpack's gold count before transfer and vault's gold count after transfer. .
🗑
|
||||
| [11.2.9] java.util.concurrent.locks benefit 1 | The ability to duplicate traditional synchronized blocks.
🗑
|
||||
| [11.2.10] java.util.concurrent.locks benefit 2 | Nonblock scoped locking—obtain a lock in one method and release it in another (this can be dangerous, though).
🗑
|
||||
| [11.2.11] java.util.concurrent.locks benefit 3 | Multiple wait/notify/notifyAll pools per lock—threads can select which pool (Condition) they wait on.
🗑
|
||||
| [11.2.12] java.util.concurrent.locks benefit 4 | The ability to attempt to acquire a lock and take an alternative action if locking fails.
🗑
|
||||
| [11.2.12] java.util.concurrent.locks benefit 5 | An implementation of a multiple-reader, single-writer lock.
🗑
|
||||
| [11.2.13] java.util.concurrent.locks.Lock interface | Lock interface is outline of the form of locking provided by the java.util.concurrent.locks package. The java.util.concurrent.locks.ReentrantLock class provides the
implementation.
🗑
|
||||
| [11.2.14] lock() method of ReentrantLock (It is recommended that you always follow the lock() method with a try-finally block, which releases the lock.) | One of the very powerful features is the ability to attempt (and fail) to acquire a lock. With traditional synchronization, once you hit a synchronized block, your thread either immediately acquires the lock or blocks until it can.
🗑
|
||||
| [11.2.15]Object obj = new Object(); synchronized(obj) { // traditional locking, blocks until acquired // work } // releases lock automatically | Lock lock = new ReentrantLock();
lock.lock(); // blocks until acquired
try {
// do work here
} finally { // to ensure we unlock
lock.unlock(); // must manually release
}
🗑
|
||||
| [11.2.16] tryLock() ==== Lock lock = new ReentrantLock(); boolean locked = lock.tryLock(); // try without waiting if (locked) { try { // work } finally { // to ensure we unlock lock.unlock(); } } | Quickly fail to acquire the lock - turns out to be powerful. You can process a different resource (lock) and come back to the failed lock later instead of just waiting for a lock to be released and thereby making more efficient use of system resources.
🗑
|
||||
| [11.2.17] There is also a variation of the tryLock method that allows you to specify an amount of time you are willing to wait to acquire the lock: | Lock lock = new ReentrantLock();
try {
boolean locked = lock.tryLock(3, TimeUnit.SECONDS);
if (locked) {
try {
// work
} finally { // to ensure we unlock
lock.unlock();
}
}
} catch (InterruptedException ex) {
// handle
}
🗑
|
||||
| [11.2.18] Another benefit of the tryLock method is deadlock avoidance.With traditional synchronization, must acquire locks in the same order across all threads. Acquiring locks in opposite order could lead to deadlock. | For eg, if you have two objects to lock against:Object o1 = new Object();Object o2 = new Object(); If synchronized using internal lock flags of both objects:synchronized(o1) {// thread A could pause here
synchronized(o2) {// work}}
🗑
|
||||
| [11.2.19]Looking at a similar example using a ReentrantLock, start by creating two locks: Lock l1 = new ReentrantLock(); Lock l2 = new ReentrantLock(); | Next, you acquire both locks in thread A:
boolean aq1 = l1.tryLock();
boolean aq2 = l2.tryLock();
try{
if (aq1 && aq2) {
// work
}
} finally {
if (aq2) l2.unlock(); // don't unlock if not locked
if (aq1) l1.unlock();
}
🗑
|
||||
| [11.2.20] IllegalMonitorStateException | only the lock(s) that were acquired are unlocked. ReentrantLock has internal counter to keep track of number of times locked/unlocked. If thread attempts to release a lock that it does not own, an IllegalMonitorStateException will be thrown.
🗑
|
||||
| [11.2.21] Advantage over traditional synchronization - avoid deadlock but you must deal with the possibility that both locks could not be acquired. Using a simple loop, you can repeatedly attempt to obtain both locks until successful | Now, even if thread A was only in possession of the l1 lock, there is no possibility that thread B could block because we use the nonblocking tryLock method. Using this technique, you can avoid deadlocking scenarios,.
🗑
|
||||
| [11.2.22] Non CPU intensive solution for making sure both locks are acquired | loop2:
while (true) {
boolean aq2 = l2.tryLock();
boolean aq1 = l1.tryLock();
try {
if (aq1 && aq2) {
// work
break loop2;
}
} finally {
if (aq2) l2.unlock();
if (aq1) l1.unlock();
}
}
🗑
|
||||
| [11.2.23] It is remotely possible that this example could lead to livelock. Imagine if thread A always acquires lock1 at the same time that thread B acquires lock2. | Each thread's attempt to acquire the second lock would always fail,repeating forever, or at least until one thread falls behind the other. Fix livelock by introducing a short random delay with Thread.sleep(int) any time you fail to acquire both locks.
🗑
|
||||
| [11.2.24]Condition is equivalent of traditional wait, notify, and notifyAll. Traditional wait and notify methods allow developers to implement await/signal pattern. await/signal pattern used for locking, but with added stipulation to avoid spinning | The character's thread could repeatedly lock the store object and check for the desired item, but that would lead to unneeded system utilization. Instead, the character's
thread can say, "I'm taking a nap, wake me up when new stock arrives."
🗑
|
||||
| [11.2.25] The java.util.concurrent.locks.Condition interface is the modern replacement for the wait and notify methods.A three-part code example shows how to use a condition.Advantage of Condition over traditional wait/notify operations | is that multiple Conditions can exist for each Lock. A Condition is effectively a waiting/blocking pool for threads.Lock lock = new ReentrantLock();blockingPoolA = lock.newCondition);blockingPoolB = lock.newCondition();
🗑
|
||||
| [11.2.26] The java.util.concurrent.locks.Condition interface (cont.) By having multiple conditions, you are effectively categorizing the threads waiting on a lock | and can, therefore, wake up a subset of the waiting threads.Conditions can also be used when you can't use a BlockingQueue to coordinate activities of two or more threads.
🗑
|
||||
| [11.2.27] Part one shows that a Condition is created from a Lock object: Lock lock = new ReentrantLock(); Condition blockingPoolA = lock.newCondition(); | When your thread reaches a point where it must delay until another thread performs an activity, you "await" the completion of that other activity. Before calling await, you must have locked the Lock used to produce the Condition.
🗑
|
||||
| [11.2.28] Condition 3 part (ctd. a) | Possibly the awaiting thread may be interrupted and you must handle the possible InterruptedException. When you call the await method, the Lock associated with the Condition is released. Before the await method returns, the lock will be
reacquired.
🗑
|
||||
| [11.2.29] |
🗑
|
Review the information in the table. When you are ready to quiz yourself you can hide individual columns or the entire table. Then you can click on the empty cells to reveal the answer. Try to recall what will be displayed before clicking the empty cell.
To hide a column, click on the column name.
To hide the entire table, click on the "Hide All" button.
You may also shuffle the rows of the table by clicking on the "Shuffle" button.
Or sort by any of the columns using the down arrow next to any column heading.
If you know all the data on any row, you can temporarily remove it by tapping the trash can to the right of the row.
To hide a column, click on the column name.
To hide the entire table, click on the "Hide All" button.
You may also shuffle the rows of the table by clicking on the "Shuffle" button.
Or sort by any of the columns using the down arrow next to any column heading.
If you know all the data on any row, you can temporarily remove it by tapping the trash can to the right of the row.
Embed Code - If you would like this activity on your web page, copy the script below and paste it into your web page.
Normal Size Small Size show me how
Normal Size Small Size show me how
Created by:
MVK2013
Popular Computers sets