• 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

Thread question

 
Ranch Hand
Posts: 178
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator



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 ]
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[ 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 ]
 
Ranch Hand
Posts: 329
Oracle Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Meena R. Krishnan
Ranch Hand
Posts: 178
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Enthuware Software Support
Posts: 4810
52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you all for commenting on this. We will add further explanation to make it clear.
 
Meena R. Krishnan
Ranch Hand
Posts: 178
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Paul and Henry!
 
Ranch Hand
Posts: 1274
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic