Busy. Please wait.

show password
Forgot Password?

Don't have an account?  Sign up 

Username is available taken
show password


Make sure to remember your password. If you forget it there is no way for StudyStack to send you a reset link. You would need to create a new account.
We do not share your email address with others. It is only used to allow you to reset your password. For details read our Privacy Policy and Terms of Service.

Already a StudyStack user? Log In

Reset Password
Enter the associated with your account, and we'll email you a link to reset your password.

Remove Ads
Don't know
remaining cards
To flip the current card, click it or press the Spacebar key.  To move the current card to one of the three colored boxes, click on the box.  You may also press the UP ARROW key to move the card to the "Know" box, the DOWN ARROW key to move the card to the "Don't know" box, or the RIGHT ARROW key to move the card to the Remaining box.  You may also click on the card displayed in any of the three boxes to bring that card back to the center.

Pass complete!

"Know" box contains:
Time elapsed:
restart all cards

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


Cert Obj Atomic Variables and Locks

[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.
Created by: MVK2013