aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Thread question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Thread question " Watch "Thread question " New topic
Author

Thread question

Meena R. Krishnan
Ranch Hand

Joined: Aug 13, 2006
Posts: 178



Which of the following is correct regarding the execution of the given program?


One of the correct answers is

"The final value of threadcounter just before the program terminates may be less than 10"


I don't agree with this. I think the final value will be atleast 10 if not exactly 10 and can never be < 10.

Here is the explanation given:
The printing of the values cannot be determined because the run() method is not synchronized. So, while a thread has incremented the threadcounter and is about to print it, another thread may increment the value.

source: Enthuware
[ May 19, 2007: Message edited by: M Krishnan ]
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[ The following post is incorrect and should be ignored. I'm leaving it here anyway only because Sergio's post won't make sense if I remove it. - Jim ]

I agree with you. They've shown the entire TestClass class, and the main(String[]) method. There is no reason to think that other threads are involved in this problem. And more importantly, even if there were other threads involved, the variable threadCounter was declared private, and there's no way for any other threads to interfere with its value. Unless they use reflection, of course... the standard exception to many, many, many statements about Java. But that's outside the scope of that the SCJP covers. The short answer is, the Enthuware answer is wrong, and should be ignored.

A longer answer might mention that ++ is not an atomic operation, and if Enthuware had written their question a little more intelligently, allowing other threads access... then the Enthuware answer might have been right. But it's not. Too bad.
[ May 20, 2007: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
Sergio Tridente
Ranch Hand

Joined: Mar 22, 2007
Posts: 329

Originally posted by Jim Yingst:
A longer answer might mention that ++ is not an atomic operation, and if Enthuware had written their question a little more intelligently, allowing other threads access... then the Enthuware answer might have been right.


I think the answer is right. There at least 11 threads involved in the snipppet: the main thread (which does not access the threadcounter class variable) and the 10 threads started from within the main method (which do access and modify the static variable).
Note that the threads' start() method is called from within a synchronized block, but that does not mean that all their run() methods will be executed one after the other. It would be possible for two threads (running concurrently) to try to increment the class' variable at the same time and if the ++ is not an atomic operation, then threadcounter may finish having a value inferior to 10.


SCJP 1.4 (88%) - SCJP 5.0 Upgrade (93%) - SCWCD 1.4 (97%) - SCBCD 5.0 (98%)
Meena R. Krishnan
Ranch Hand

Joined: Aug 13, 2006
Posts: 178
I kind of got it and still I feel the explanation by Enthuware is not very clear.

Can you please explain a bit on "if the ++ is not an atomic operation," ?

Thanks
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 19073
    
  40

Originally posted by M Krishnan:
I kind of got it and still I feel the explanation by Enthuware is not very clear.

Can you please explain a bit on "if the ++ is not an atomic operation," ?

Thanks


Basically, the Java specification doesn't define the increment operator as being atomic to memory. In terms of implementation, the bytecodes that is generated by the compiler is likely to be a load from memory, add one, and a store back to memory.

It is not atomic because another thread can do something between the load and the store. For example, what if two threads do a increment. Both thread load the original value, both will add one, and both will store. If it is done in that order, then the value will be incremented by one -- not the correct answer of two.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Paul Anilprem
Enthuware Software Support
Ranch Hand

Joined: Sep 23, 2000
Posts: 3336
    
    8
Thank you all for commenting on this. We will add further explanation to make it clear.


Enthuware - Best Mock Exams and Questions for Oracle/Sun Java Certifications
Quality Guaranteed - Pass or Full Refund!
Meena R. Krishnan
Ranch Hand

Joined: Aug 13, 2006
Posts: 178
Thanks Paul and Henry!
Burkhard Hassel
Ranch Hand

Joined: Aug 25, 2006
Posts: 1274
Hi ranchers,

something you may try out:
put a yield(); after the increment step of the run-method.

Yours,
Bu.
[ May 20, 2007: Message edited by: Burkhard Hassel ]

all events occur in real time
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Hm, now I can't tell if I simply overlooked the loop starting multiple threads, or if that was added after I posted. Either way, my last post is not correct for the code that's currently shown, so ignore it. The stated Enthuware answer is correct. Sorry for the confusion.
[ May 20, 2007: Message edited by: Jim Yingst ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Thread question