• 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: 317
Eclipse IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This question is from here

Question is :

These classes are defined in a single file. There’s a value object Account that carefully protects it’s state from concurrent access, a Client class of type Thread that puts some money in an account, and a main method that simply starts two clients.



Just before the main method exits, the account’s number field is guaranteed to have value 2000.

1. true
2. false


As per the site answer is false. but as per my understanding it should be true. Because the execution will be terminate after the execution of both the thread is completed and both the methods of Account class are synchronized so the only one thread can execute the methods at a time. Can any one please explain why the answer is false. I have tried this example so may times but every time 2000 is the value of "number" field of Account class.

 
Harpreet Singh janda
Ranch Hand
Posts: 317
Eclipse IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oh i got the answer.

As both the methods are synchronized but both are being call from non synchronized context so there is a possibility that both thread can read the same value.

Correct me if i am wrong.
 
Ranch Hand
Posts: 247
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Harpreet Singh janda wrote:
...As per the site answer is false. but as per my understanding it should be true. Because the execution will be terminate after the execution of both the thread is completed and both the methods of Account class are synchronized so the only one thread can execute the methods at a time. Can any one please explain why the answer is false. I have tried this example so may times but every time 2000 is the value of "number" field of Account class.



I agree with you and am baffled about why the answer is false. In the main method, the two calls to the join() method means the two Client threads will finish and die first before the main method exits. That should guarantee that the number field will be incremented to 2000. It seems to me.
 
Harpreet Singh janda
Ranch Hand
Posts: 317
Eclipse IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Suppose Thread one reads the number using getNumber method, As because this method is synchronized so only one thread can execute it at a time. Return value of thisi method is passed as parameter to setNumber method. When Thread one get the number using getNumber it will release the lock and try to regain the lock before starting the execution on setNumber method mean while second thread two can go to getNumber method before thread one could regain the lock and execute setNumber method. At this point both the thread will get same number and will set the same number after incrementing it.
 
Ranch Hand
Posts: 234
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Answer should be true.

Reason is:

Each object has just one lock.

Thread one will first try to take the lock on setNumber() method. When it will get the lock, it will call getNumber() method. (Please pay attention here - setNumber method is still not over). When it will finish getNumner() method, it still has the lock with it. Thread one will release the lock only after completing setNumner method. I think both the method will act as a atomic operation. Lock will get released only after execution of both the methods.

Let me know if I am not correct
 
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

Brij Garg wrote:
Thread one will first try to take the lock on setNumber() method. When it will get the lock, it will call getNumber() method. (Please pay attention here - setNumber method is still not over). When it will finish getNumner() method, it still has the lock with it. Thread one will release the lock only after completing setNumner method. I think both the method will act as a atomic operation. Lock will get released only after execution of both the methods.



No. The lock is grab upon entry to the method, not when it is encountered during the evaluation of the expression.

Henry
 
Harpreet Singh janda
Ranch Hand
Posts: 317
Eclipse IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thread will first acquire the lock on getNumber then will release the lock and then again will try to gain the lock on setNumber method. This will not be an atomic operation.

In case where a method is being called in the parameter list, first the internal (method which is being called in the parameter list) method will be evaluated then the argument will be replaced by the return value. This will not be like first outer method(setNumber) will be called and the internal method (getNumber )will be called to evaluate the parameter.
reply
    Bookmark Topic Watch Topic
  • New Topic