Like the book, I'm actually doing my SCJD but needed to brush up on my 1.5, I only browsed the chapter as it didn't appear to introduce anything above 1.4 and I do a lot of threading.
My issue is with Self Test : Question 9 / Chapter 9 / Threads I don't agree with the answer.
I looked in the previous errata list and didn't find this one, apologies if its there or I've miss read the question (its a threading question so its difficult to prove) ...
In your answer you state
there will be no return from wait call because no other thread will notify the main thread
but in the case of spurious thread wake up the thread could just wake up from the wait... which you mention on page 727 (also in Sun docs etc etc) ?? i.e. yes no other thread will call notify (that we know about) but the JVM can effectively call notify, good coding practice is to be in a loop and test for this after returning from the wait.
Surely the answer is B) 1 2 3 not D) 1,2 ?
( although it will be very rare to get a 3 but possibly easier to do this with a JVM 1.6 (from Sun) )
A very good catch indeed. But i didn't get how we can only go for 1 2 3 as a result. why not 1 2 also. So my point is: 1) Either we need to change the answer Answer 9> "Output can't be determined". 2) or change the question itself so that wait() method upon awaking check for whether it has got what it was waiting for. ex: like wait until a list gets populated. What do you say?
Can you write a structured argument for D then please as I say its B) ? i.e. just saying its D) is a bit pointless :-(
My point is if I run it on my PC I might get B and you might get D and I think saying "thats what my JVM does is not a valid defence" or even most JVMs will do this as you could re argue most thread multiple choice questions in that case.
I guess the exact answer to what is the result is undefined (and that is the only correct answer and NOT an option) , if it said expected behaviour maybe you could suggest D (but thats still an awful question)
My personal preferrence would be for the whole question to be dropped, all multiple choice questions should have exact answers.
There is a great thread on sun's site where an IBM engineer tries to argue that because his code never exhibited spurious thread wake up prior to 1.6. it shouldn't now and it was therefore a bug in the 1.6 JVM , he didn't win the argument either.
Joined: Jan 10, 2007
Mhhh. well, SUN is saying
thread can also wake up without being notified, interrupted, or timing out, a so-called spurious wakeup. While this will rarely occur in practice,...
In my opinion it's declaring a bug as a feature.
As soon as you have multi-threading (or even single threading), there is no absolute guaranty for a result. If you create a new thread in JAVA, there is no guaranty that it ever will be executed.
But you're right. This "feature" of accidently waking up a thread will allow answer B), too.
I certainly wish spurious thread wake up would go away but as we have it its certainly something a good thread programmer should be aware of and what you can and can't predict as behaviour I believe is part of the exam, the mocks and the last time I sat the SCJP you would usually find questions with an option of "The ouput cannot be determined", the style of question in all the other questions in this section is ok, i.e. you can write questions about what will happen as long as your vague enough about it e.g. question 17.
Every book on threading I've read and thats a lot including the chapter of this one mentions that you should execute a wait from within a loop including the Java specification Notification 17.8.2 of my copy of the JSL says ...
Implementations are permitted,although not encouraged, to perform ``spurious wake-ups'' -- to remove threads from wait sets and thus enable resumption without explicit instructions to do so. Notice that this provision necessitates the Java coding practice of using wait only within loops that terminate only when some logical condition that the thread is waiting for holds.
The code as listed in the question purposely does not follow this practice and the answer ignores the consequences of this folly. This kinda of things pops up in real code.
There are guarantees about thread behaviour (in the JSL), you just have to be careful about what they are I think its quite reasonable to test anything that the JSL says Java will do but not anything it says don't.
The problem is when some one comes to me (several companies) and says every month or so my system falls over for no reason this is the kind of thing I have to try and eliminate if they just put a loop into I wouldn't have to (admitedly if Java didn't do this would be a win too but it does), volatile variables is the other big one the number of times I find code written by others thats been working for weeks \ months that doesn't have proper memory barriers in is also quite large and I'm including some open source libraries in this, I've worked on corrections to.
Again I would drop the question , as an essay question this would be fine i.e. the conclusion could be either and what the examiner would look for is the structured argument, as a multiple choice questions its flawed.