• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Problem with Java 2 SCJP Certification Study Guide???

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have been trying to understand the threads chapter (CH 9) in the Java 2 SCJP Study Guide written by Bert Bates, and Kathy Sierra. This question is very specific and related to page 531. I will attempt to give a synopsis of the sceanrio which the authors are attempting to explain, and then state either the problem with the code example they provide, or demonstrate my misunderstanding of the principles they are trying to teach. Since I am pretty new to threads, and I consider it very important for the exam, and in real life, I would like to know what the correct answer is!!!

Notify and Wait (Thread Interaction) Scenario

A user interfaces with an Operator object (Thread). The Operator class interfaces with a Machine object (Thread), which in turn interfaces with the actual Hardware. The user inputs a new shape for the Machine to cut, and the operator object gets this information from the user. The Machine object actually instantiates the operator object (Thread) and then waits until the operator object has completed calculating the Machine steps necessary to send to the Hardware based on the user input. Once this has been completed a notify signal is sent, and the Machine object then sends the Machine steps calculated by the Operator object to the specific Hardware. A common object used by both the Hardware object, and the Operator object, stores the actual Machine cutting steps.

Here is the applicable code and some (but not all) text as written by the authors: (Note: They only included the Operator and Machine class code):

" It is important that the user thread does not modify the machine steps while the hardware thread is using them, so this reading and writing should be synchronized. The resulting code would like this:


class Operator extends Thread {
public void run() {
while (true) {
// Get shape from user
synchronized (this) {
// Calculate new machine steps from shape
notify();
}
}
}
}

class Machine extends Thread {
Operator operator; //assume this gets initialized
public void run() {
while(true) {
synchronized(operator) {
try {
operator.wait();
} catch (InterruptedException ie) {}
// Send machine steps to hardware
}
}
}
}

.......While one shape is being processed by the hardware, the user may interact with the system and specify another shape to be cut. When the user is finished with the shape and it is time to cut it, the operator thread attempts to enter the synchronized block, maybe blocking until the machine thread has finished with the previous machine steps. When the machine thread has finished, it repeats the loop, going again to the waiting state (and therefore releasing the lock). Only then can the oprator thread enter the synchronized block and overwrite the machine steps with the new ones. "

PROBLEM (as I see it): After startup, and assuming the Operator thread is blocking until the Machine thread finishes, the code does not match the authors description of what happens after the Machine thread finishes sending steps to the hardware. For example, as currently written, the Machine thread would block while attempting to aquire a lock on the operator object (not wait)after finishing the previous machine steps, while the operator thread would then be calculating new machine steps. After the operator thread completed those steps, it would send a notify signal, but since the machine thread had not yet called wait at this point, this notify signal (and a whole set of machine instructions)is wasted (I think?). After the operator thread exited the synchronized block, the machine thread would acquire the operator objects lock and then wait until more user input and futher machine steps were calculated by the operator thread and another notify signal was sent.

CONCLUSION:
I am guesing a little bit, but their description makes a whole lot more sense (and it also seems to me to be better code anyway) if the while(true) and synchronized(operator) lines are swapped. I am pretty sure this is what was intended, but since I am fairly new to threads, I would like to make sure I understand this section thoroughly. For example, if I am wrong, in my opinion, I don't understand enough about the notify () method, etc.

Please let me know whether my analysis and conclusions are correct, or if I am out in left field. If I am out there, any additional information concerning the notify method and how it works would be appreciated.

Thanks.

Rick
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
a) The infinite loop in both respective objects is fine. So there is no need to swap while/synchronized statements in each class. The logic is that once the respective threads are started, they keep running.
An additional try/catch immediately after the loop would be more secure because currently some exceptions would still result in the thread to exit but I guess the authors were just concerned with illustrating the threading behavior and not providing production-grade code

b) Let me explain the possibility of notify signal being lost under the scenario you explained. With the way the snippet is written exactly -- yes notify will be lost.

But you can deal with it in two ways:
Algorithm#1.
- operator will check a flag that queue is empty before assigning a new operation to the machine
- if the queue is not empty, and the setup is to process only one job at a time, operator could display a "busy" message to the user or block until the machine finishes the previous job and is free to take the next one (both objects will implement a wait)

Algorithm#2.
- operator will just add more jobs to end of queue and call notify again.
- this time the machine will catch notify and pick up both the jobs.


Ref: java.sun.com/docs/books/tutorial/essentials/threads/waitAndNotify.html for a better example of implementing producer/consumer scenario.
 
I claim this furniture in the name of The Ottoman Empire! You can keep this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic