Suppose
a gas station has a single toilet, the key for which is kept at the
service desk. The toilet is a shared resource for passing motorists.
To use this shared resource the prospective user must acquire a key
to the lock on the toilet. The user goes to the service desk and
acquires the key, opens the door, locks it from the inside and uses
the facilities.
Meanwhile,
if a second prospective user arrives at the gas station he finds the
toilet locked and therefore unavailable to him. He goes to the
service desk but the key is not there because it is in the hands of
the current user. When the current user finishes, he unlocks the door
and returns the key to the service desk. He does not bother about
waiting customers. The service desk gives the key to the waiting
customer. If more than one prospective user turns up while the toilet
is locked, they must form a queue waiting for the key to the lock.
Each thread has no idea who is in the toilet.
Obviously
in applying this analogy to Java, a Java thread is a user and the
toilet is a block of code which the thread wishes to execute. Java
provides a way to lock the code for a thread which is currently
executing it using the synchronized keyword, and making other threads
that wish to use it wait until the first thread is finished. These
other threads are placed in the waiting state. Java is NOT AS FAIR as
the service station because there is no queue for waiting threads.
Any one of the waiting threads may get the monitor next, regardless
of the order they asked for it. The only guarantee is that all
threads will get to use the monitored code sooner or later.
Here,
key or the service desk is object class which has wait() and notify()
methods. Here key and service desk are not theads.
If
wait() and notify() were on the Thread instead then each thread would
have to know the status of every other thread. How would thread1 know
that thread2 was waiting for access to a particular resource? If
thread1 needed to call thread2.notify() it would have to somehow find
out that thread2 was waiting. There would need to be some mechanism
for threads to register the resources or actions that they need so
others could signal them when stuff was ready or available.
In
Java, the object itself is the entity that is shared between threads
which allows them to communicate with each other. The threads have no
specific knowledge of each other and they can run asynchronously.
They run and they lock, wait, and notify on the object that they want
to get access to. They have no knowledge of other threads and don't
need to know their status. They don't need to know that it is thread2
which is waiting for the resource – they just notify on the
resource and whomever it is that is waiting (if anyone) will be
notified.
No comments:
Post a Comment