Threading - SCJD Exam with J2SE 5 - page 77

Or imagine a producer/consumer relationship where one thread populates an object and
another consumes that object when it is populated. In this case, the consumer thread wants
the object to be modified; thus, the consumer wants to know when that modification occurs.
Object.wait , Object.notify , and Object.notifyAll support the latter kind of waiting.
Calling the wait method is different than calling sleep or yield , or even pausing for I/O.
The wait method actually allows other threads to acquire the lock on the object in question,
while sleep , yield , and pausing for I/O do not.

■

Note The wait and notify / notifyAll methods almost always go together. If one thread wait s, there
should be another thread that can call notify or notifyAll . The exception to this would be if you were
doing something with timeouts and needed to release locks—but this would be a very rare situation. If
there's no call to a wait method, then there's no reason at all to call notify or notifyAll .

Yielding
Yielding is the act of politely offering up your turn in the queue while maintaining your
resources. For example, suppose you're trying to use a bank's automated teller machine
(ATM). You know that this process will take a while because you're going to transfer funds,
check your balance, make a deposit, and so forth. Yielding would be the act of offering the
person behind you in line an opportunity to use the ATM before you. Of course, you wouldn't
give that person your resources (money, ATM card, and so on). However, you would offer
to give up your spot at the ATM (analogous to the CPU). The process of making this offer,
even if there's no one to accept it, is yielding.
It is possible that, even though you yielded, you may still get first access. In our ATM
scenario it is possible that the person behind you is too nice to accept your kindness. In com-
puter terms, though, when you yield, all threads (including your own) then get to compete for
the lock on the object—your thread does not get a lesser or greater chance of getting the lock
on the object. But what decides which thread actually wins that competition and gets access
to the lock on the object? The thread scheduler does.
The thread scheduler is like an office manager. It takes threads into consideration and
decides which thread should be allowed to run based on the underlying operating system,
thread priorities, and other factors.
There are two important points to note. First, you must be aware that your thread of
execution is not guaranteed to be next in line when you yield, even though you originally vol-
unteered to give up the CPU. Once a thread yields and the CPU is taken by another thread, the
original yielding thread does not have any special status in being next in line. It must wait and
hope, like every other thread.
Second, it's important to realize that your thread didn't give up resources that you have
exclusive locks on. That is, even though you're letting someone else use the ATM, you didn't
give him your ATM card. When a thread yields, it steps out of the CPU, but it retains control
over any resources it had originally marked for exclusive use.
So why yield? Imagine that your thread entails six small bank operations: checking your
balance, moving money from your checking account to your everyday account, checking
your balance, moving money from your savings account to your everyday account,
checking your balance, and finally withdrawing money. The thread you're yielding to might