Help
Options
Didn't know it?
click below
click below
Knew it?
click below
click below
Don't Know
Remaining cards (0)
Know
retry
shuffle
restart
0:00
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
OCPJP710.3
Cert Obj Synchronize thread access to shared data.
| [10.3.1] Certification Objective | Synchronize thread access to shared data. |
| [10.3.2] Who gets control once a lock is released? | It is not possible to do so. Thread can only release the lock and it has no control over who gets the lock next. All the waiting threads compete to get the lock and any one of them can get it. |
| [10.3.3] Beware of 2 for loops on static variable | None of the threads has synchronized access to the variable. So there is no guarantee which thread will access it when. Further, one thread might increment i while another is executing i<5. So it is possible that more than 5 words may be printed. |
| [10.3.4] Can any class be used as a monitor? | Any object can be a monitor. wait()/notify() methods are in Object classes and not in Thread class. |
| [10.3.5] Thread going to sleep has lock | Lock is not released when a thread sleeps |
| [10.3.6] The Java programming language provides multiple mechanisms for communicating between threads. What is a monitor? | The most basic of these methods is synchronization, which is implemented using monitors. Each object in Java is associated with a monitor, which a thread can lock or unlock. |
| [10.3.7] Only one thread at a time may hold a lock on a monitor. Any other threads attempting to lock that monitor are blocked until they can obtain a lock on that monitor. | A thread t may lock a particular monitor multiple times; each unlock reverses the effect of one lock operation. |
| [10.3.8]The synchronized statement (§14.19) computes a reference to an object; it then attempts to perform a lock action on that object's monitor and does not proceed further until the lock action has successfully completed. | After the lock action has been performed, the body of the synchronized statement is executed. If execution of the body is ever completed, either normally or abruptly, an unlock action is automatically performed on that same monitor. |
| [10.3.9] A synchronized method (§8.4.3.6) automatically performs a lock action when it is invoked; its body is not executed until the lock action has successfully completed. | If the method is an instance method, it locks the monitor associated with the instance for which it was invoked (that is, the object that will be known as this during execution of the body of the method).. |
| [10.3.10] A synchronized method (§8.4.3.6) automatically performs a lock action when it is invoked; its body is not executed until the lock action has successfully completed. | If static, it locks the monitor associated with the Class object which the method is defined. If execution of the method's body is ever completed, either normally or abruptly, an unlock action is automatically performed on that same monitor. |
| [10.3.11] Alternate ways of synchronization? | Other mechanisms, such as reads and writes of volatile variables and the use of classes in the java.util.concurrent package, provide alternative ways of synchronization. |
| [10.3.12] Wait Sets and Notification | Every object, in addition to having an associated monitor, has an associated wait set. A wait set is a set of threads. |
| [10.3.13] Wait sets are manipulated solely through the methods Object.wait, Object.notify, and Object.notifyAll. | When an object is first created, its wait set is empty. Elementary actions that add threads to and remove threads from wait sets are atomic. |
| [10.3.14] Wait set manipulations can also be affected by the interruption status of a thread, and by the Thread class's methods dealing with interruption. | Additionally, the Thread class's methods for sleeping and joining other threads have properties derived from those of wait and notification actions. |
| [10.3.15] Wait actions occur upon invocation of wait(), or the timed forms wait(long millisecs) and wait(long millisecs, int nanosecs). | A call of wait(long millisecs) with a parameter of zero, or a call of wait(long millisecs, int nanosecs) with two zero parameters, is equivalent to an invocation of wait(). |
| [10.3.16] A thread returns normally from a wait if it returns without throwing an InterruptedException. | Let thread t be the thread executing the wait method on object m, and let n be the number of lock actions by t on m that have not been matched by unlock actions. One of the following actions occurs: |
| [10.3.17a] •If n is zero (i.e., thread t does not already possess the lock for target m) | ... then an IllegalMonitorStateException is thrown. |
| [10.3.17b] •If this is a timed wait and the nanosecs argument is not in the range of 0-999999 or the millisecs argument is negative | ... then an IllegalArgumentException is thrown. |
| [10.3.17c] •If thread t is interrupted | ... then an InterruptedException is thrown and t's interruption status is set to false. |
| [10.3.17d] •Otherwise, the following sequence occurs: | 1.Thread t is added to the wait set of object m, and performs n unlock actions on m. |
| [10.3.17e] | 2.Thread t does not execute any further instructions until it has been removed from m's wait set. The thread may be removed from the wait set due to any one of the following actions, and will resume sometime afterward: |
| [10.3.17f] | ◦A notify action being performed on m in which t is selected for removal from the wait set. ◦A notifyAll action being performed on m. ◦An interrupt action being performed on t. |
| [10.3.17g] ctd | ◦If this is a timed wait, an internal action removing t from m's wait set that occurs after at least millisecs milliseconds plus nanosecs nanoseconds elapse since the beginning of this wait action |
| [10.3.17h] Notice that this provision necessitates the Java coding practice of using wait only within loops that terminate only when some logical condition that the thread is waiting for holds. | ◦An internal action by the implementation. Implementations are permitted, although not encouraged, to perform "spurious wake-ups", that is, to remove threads from wait sets and thus enable resumption without explicit instructions to do so. |
| [10.3.17i] Each thread must determine an order over the events that could cause it to be removed from a wait set. That order does not have to be consistent with other orderings, but the thread must behave as though those events occurred in that order. | eg, if a thread t is in the wait set for m, and then both an interrupt of t and a notification of m occur, there must be an order over these events. |
| [10.3.17j]If interrupt is deemed to have occurred first, then t will eventually return from wait by throwing InterruptedException, and some other thread in the wait set for m (if any exist at the time of the notification) must receive the notification. | If the notification is deemed to have occurred first, then t will eventually return normally from wait with an interrupt still pending. |
| [10.3.17k] ctd from e | 3.Thread t performs n lock actions on m. |
| [10.3.17l] ctd | 4.If thread t was removed from m's wait set in step 2 due to an interrupt, then t's interruption status is set to false and the wait method throws InterruptedException. |
| [10.3.18a]Notification actions occur upon invocation of methods notify and notifyAll. | Let thread t be the thread executing either of these methods on object m, and let n be the number of lock actions by t on m that have not been matched by unlock actions. One of the following actions occurs: |
| [10.3.18b] | •If n is zero, then an IllegalMonitorStateException is thrown. This is the case where thread t does not already possess the lock for target m. |
| [10.3.18c] No guarantee re - which thread in the wait set. removal from the wait set enables u's resumption in a wait action. Notice, however, that u's lock actions upon resumption cannot succeed until some time after t fully unlocks the monitor for m. | •If n is greater than zero and this is a notify action, then if m's wait set is not empty, a thread u that is a member of m's current wait set is selected and removed from the wait set. |
| [10.3.18d] Notice, however, that only one of them at a time will lock the monitor required during the resumption of wait. | •If n is greater than zero and this is a notifyAll action, then all threads are removed from m's wait set, and thus resume. |
| [10.3.19] Interruptions Interruption actions occur upon invocation of Thread.interrupt, as well as methods defined to invoke it in turn, such as ThreadGroup.interrupt. | Let t be the thread invoking u.interrupt, for some thread u, where t and u may be the same. This action causes u's interruption status to be set to true. |
| [10.3.20]Additionally, if there exists some object m whose wait set contains u, then u is removed from m's wait set. This enables u to resume in a wait action, in which case this wait will, after re-locking m's monitor, throw InterruptedException. | Invocations of Thread.isInterrupted can determine a thread's interruption status. The static method Thread.interrupted may be invoked by a thread to observe and clear its own interruption status. |
| [10.3.21] Interactions of Waits, Notification, and Interruption The above specifications allow us to determine several properties having to do with the interaction of waits, notification, and interruption. | A thread both notified and interrupted while waiting may either: •return normally from wait, while still having a pending interrupt (in other words, a call to Thread.interrupted would return true) •return from wait by throwing an InterruptedException |
| [10.3.22]The thread may not reset its interrupt status and return normally from the call to wait. | Similarly, notifications cannot be lost due to interrupts. Assume that a set s of threads is in the wait set of an object m, and another thread performs a notify on m. Then either: |
| [10.3.23] Note that if a thread is both interrupted and woken via notify, and that thread returns from wait by throwing an InterruptedException, then some other thread in the wait set must be notified. | •at least one thread in s must return normally from wait, or •all of the threads in s must exit wait by throwing InterruptedException |
| [10.3.24] Sleep and Yield Thread.sleep causes the currently executing thread to sleep (temporarily cease execution) for the specified duration, subject to the precision and accuracy of system timers and schedulers. | The thread does not lose ownership of any monitors, and resumption of execution will depend on scheduling and the availability of processors on which to execute the thread. |
| [10.3.25]It is important to note that neither Thread.sleep nor Thread.yield have any synchronization semantics. | In particular, the compiler does not have to flush writes cached registers out to shared memory before a call to Thread.sleep or Thread.yield, nor does the compiler have to reload values cached in registers after a call to Thread.sleep or Thread.yield. |
| [10.3.26] For example, in the following (broken) code fragment, assume that this.done is a non-volatile boolean field: while (!this.done) Thread.sleep(1000); | The compiler is free to read the field this.done just once, and reuse the cached value in each execution of the loop. This would mean that the loop would never terminate, even if another thread changed the value of this.done. |
Created by:
MVK2013
Popular Computers sets