Ok hello all, my name's Aaron, and this is my first post on this forum!
My interest in programming started when I attempted to design a system to aid in trading systems (about a year ago). My knowledge has literally started from the ground up. While my knowledge base has grown, so has my realisation of what I don't know (which would make me a wise man according to socrates). I started learning the basics, writing small programs, games etc. I was thinking to my self, while I'm learning this stuff wouldn't it be nice to have something to show for it - hence my desire to complete the SCJP. I bought Kathy and Bert's SCJP study guide, and read! Wow, what a great overview of programming concepts in general. I realised that up to the point of reading the book I had been doing everything the 'hard' way so to speak (tackling my own 'collection' management system, my own serialization, etc). Now since studying the book I realise just how little I know overall, and sometimes I confuse myself with certain concepts. I know that given time these concepts will be drilled in. And this brings me to the topic of my first post; Threads.
I don't if anyone would agree with the statement; Threads are hard for beginners to visualise, espec. synchronization (locks, monitors)!! If you do, then please read on and try to help me if you can...
My problem specifically relates to an example in the text above, Kathy and Bert's SCJP study guide. You can find the example on pages 754 -755. I'm not sure if I am allowed to copy the text for publishing issues but anyway, this is a rough picture..
A couple of pages before, an outline of a system is proposed.
Within this system there is a user, and a machine.
The user selects shapes. The machine makes the shape.
The user has to send the shapes to the machine, using some software interaction.
It is proposed that the best solution is via Thread interaction. WHY? Because then the user can still continue to select shapes while the machine does its bit.
While the example mainly tries to tackle the importance of the wait(), and notify() methods, as well as iterating the point that for sound coding the wait() method should be placed within a while(...) loop to continually check the wait conditions... my point is more related to the overall design of the system. Bare with me please guys and girls...
Going over the code in the book, I argue that the system proposed, or rather the design approach would only allow the user to select a maximum of one other shape while the machine is processing the code, and not MULTIPLE shapes! Maybe i'm missing something here, but it seems that if both user and machine classes have code that synchronises with the 'list of things to do'... then while 'things are added' the 'machine cannot access the list', and while 'the machine is using the list' 'things cannot be added'. simple synchronisation right? if for example, the machine class just sends the hardware instructions and that takes less time that it does for the user to select the shape then in reality there's no problem. BUT, theoretically speaking, is my thinking right? if the machine class sends the hardware instructions within the synchronised code then there could never ever be more than one instruction, right? or wrong?
Your point is correct and the book also states the same in the next para: "...Having two threads is definitely an improvement over having one, although in this implementation there is still a possibility of making the user wait. A further improvement would be to have many shapes in a queue, thereby reducing the possibility of requiring the user to wait for the hardware...".