Java Reference
In-Depth Information
you will know that the thread will resume processing when it has been notified, or soon after
the time limit has expired. Remember that time limits cannot be strictly enforced; the JVM will
pause the thread at least as long as you requested and make its best attempt to schedule the
thread after the time limit has expired, but the exact time the thread resumes is not guaranteed.
If you call sleep , you will know that the thread will resume processing soon after the time limit
has expired—again, time limits cannot be strictly enforced. Returning to the ice cream exam-
ple, imagine that little Sally has finally gotten the ice cream man's attention and given him
some money, but she hasn't yet actually picked her flavor. If Sally yielded, then she would
move out of the way voluntarily to let another child try, but she would be secure in the knowl-
edge that the ice cream man won't sell the cone that she explicitly locked down. If no children
were in fact interested, then she would jump back in and have her cone filled with ice cream.
If Sally decided to sleep , it might be as if she has put her money down for a cone but is
delaying making her choice for up to 1 minute—say, for her younger brother to arrive. After
the minute has elapsed, then she will try again (whether the younger brother has shown up or
not). When she finally does get the ice cream man's attention, she will be confident that the ice
cream cone she had locked down will still be there. But just because Sally has decided that the
minute is up does not mean that she will be able to get her cone immediately—another child
may be getting his or her cone filled at the end of Sally's minute. Sally is blocked whenever she
cannot get the ice cream man's attention. Having slept for 1 minute in the previous example,
she now finds that the ice cream man is serving another child. Although she still owns the lock
on her cone, she does not own the lock on the ice cream man and is blocked until she can get
that lock (and maybe her brother can turn up in the meantime).
However, if Sally had to wait for her father to bring her money, then she does not have any
cone locked down, and by the time the money arrives, all the cones may be sold.
Locks
Locks are tokens of exclusive use. Each Java object has one. Think of locking as the ability to
stick a note on any object and claim that object for your thread's exclusive use. By claiming an
object's lock, your thread tells other methods (those that respect synchronization) not to mod-
ify that object in any way until your thread releases it. A method that respects synchronization
is one that synchronizes on the object in question.
In Java, you can lock an object by synchronizing on it. Consider the following example:
public void addElement(Object item) {
synchronized (myArrayList) {
//do stuff
}
}
This lets the JVM know that other threads should not modify the myArrayList object. Of
course, this only applies to synchronized methods. For instance, in the following example the
method elementExists might have no need to synchronize access, because it is a read-only
operation:
public boolean elementExists(Object item) {
return myArrayList.contains(item);
}
Search WWH ::




Custom Search