Whizlabs Practice Exam 6 Question 34 Multiple object of MyClass are used in a program that uses multiple Threads to create new integer count. What will happen when other threads use the following code?
My question is: when you read the question, can you tell whether different threads use different instances of MyClass? Edited: fixed nextCount() [ September 15, 2003: Message edited by: Marlene Miller ]
Not really. But my position is that if a question mentions multiple threads and does not give any other assurances, we should assume that multiple threads may have access to the same shared instances. Questions about threading are usually testing to see if you can think of all the worst-case scenarios that haven't been explicitly guaranteed against. In this particular case, assuming that nextCount was supposed to be nextCount(), it doesn't seem to matter much. Any time any thread calls getYourNumber(), using any instance, myCount gets updated correctly, and the instance used gets the that same value as its yourNumber. Dunno what they actually ask after this, but the code looks reasonably thread-safe.
"I'm not back." - Bill Harding, Twister
Joined: Mar 05, 2003
Thank you Jim for your opinion. I was curious how other people interpreted the question. Please consider this scenario. Suppose Thread-1 and Thread-2 invoke getYourNumber() on the same object in this way, Thread-1: invokes getYourNumber() Thread-1: invokes nextCount() Thread-1: nextCount() returns 1 // 1 is on the operand stack Thread-2: invokes getYourNumber() Thread-2: invokes nextCount() Thread-2: nextCount() returns 2 // 2 is on the operand stack Thread 2: yourNumber = 2 // push from operand stack Thread-1: yourNumber = 1 // push from operand stack Thus, two threads invoke getYourNumber and the result is 1. The state of the object is corrupted.
Joined: Jan 30, 2000
Yes, in this example the value of yourNumber may be viewed as corrupt. Or at least, incorrect. If we were expecting that yourNumber was supposed to be the total number of times that getYourNumber() has been invoked. Then again, this isn't documented, and youNumber isn't actually returned from the method. Though the yourNumber field is package-access, so it's posssible someone might access it, albeit in a non-thread-safe manner. So again, it's not really clear to me how the yourNumber field was intended to be used; thus, my comment that I'm not sure it matters. But you're right that there's at least a good chance this code may not produce the "intended" results, if we make some guesses about what's intended.