• Post Reply Bookmark Topic Watch Topic
  • New Topic

How comes the inconsistence ?  RSS feed

 
Ellen Zhao
Ranch Hand
Posts: 581
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To avoid retrieving the same record of a bank account simultaneously by more than one object, the withdraw() and deposit() methods were written as below:

In the code, a lock is being used. The question is: Is there still any inconsistence? I implemented the class and ran it, it seems okay. But intuitively I know there is some inconsistence. Were the methods not given, I would choose syncronized methods or block for sure. How comes the inconsistence in the code above? Could anybody please kindly tell me? Thank you in advance.

Regards,
Ellen
 
John Lee
Ranch Hand
Posts: 2545
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When two threads race for withdraw() or deposit(), they may both get into exacution, if there is very little difference in time they call the methods. That is before thread A set lock = true, thread B has start to excute the method.
 
Ellen Zhao
Ranch Hand
Posts: 581
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Don Liu:
When two threads race for withdraw() or deposit(), they may both get into exacution, if there is very little difference in time they call the methods. That is before thread A set lock = true, thread B has start to excute the method.

Yeah I had thought of this condition, but...will it really happen? I think it will only happen when two threads get the " unlocked " information from the system in the same time, but actually in a process, two threads can never really be executed at the same time point. Once a thread gets the " unlocked " information, it locks the account at once, then no other thread can access the account. Anybody could tell any misconception in my understanding? I appreciate you very much.

Regards,
Ellen
 
John Lee
Ranch Hand
Posts: 2545
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ellen Fu:
Once a thread gets the " unlocked " information, it locks the account at once, then no other thread can access the account.

It is not 'at once', still takes time. During that time, another thread may pass the if (!lock) step.
An example will be:
The bank do direct-deposit to your account, almost at the same time, you withdraw money.
 
Ellen Zhao
Ranch Hand
Posts: 581
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don,
I get it. Thank you very much.
Ellen
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ellen Fu:
Yeah I had thought of this condition, but...will it really happen?
Yes. You made the incidence of threading problems very small, but it is still there; if thread A is suspended between the lock test and the assignment, you have a problem. And also, you're making the mistake of thinking in terms of a single CPU. Today, many enterprise systems have multiple CPUs. Tomorrow, your very own home computer will have a HyperThreading CPU which executes multiple threads simultaneously.
- Peter
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is another issue - that of cached memory. In Java, every thread is allowed to have its own memory cache. So if one thread sets the lock, it is not guaranteed that another thread will see the same value immediatly. Only by leaving a synchronized block is it guaranteed that the first will write the value to main memory. Respectively, only by entering a synchronized block you are assured that the thread updates its variables from main memory.
 
John Lee
Ranch Hand
Posts: 2545
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ellen, you are welcome!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!