Deadlock problem with bank situation

I have a 开发者_如何学JAVAproblem, i cannot resolve this problem

void Transfer(Account a, Account b, decimal amount) 
{
       lock (a) {
             lock (b) {
                         if (a.Balance < amount)
                         throw new InsufficientFundsExc();
                         a.Balance -= amount;
                         b.Balance += amount;
                         }
                   }
}

and question is " this is a transfer between bank accounts. "lock(...)" structure is used against race condition. What is this problem? and what solution do you propose? CAN YOU HELP ME?

if you have a transfer from A to B at the same time as a transfer from B to A it can deadlock because you have no lock order.

• Thread 1 locks A
• Thread 2 locks B
• Thread 1 waits on B
• Thread 2 waits on A
• dead

But why the hell is this code multithreaded in the first place?

You need to take your locks always in the same order. For example by giving each lock an integer Id and always locking the lower ID first.

If you can order the accounts (by ID number or something), you can always lock the one with the lower ID first. This will ensure that no thread tries to lock a then b at the same time as another thread locking a then b, as they will both lock a first.

deadlock

when Transfer(a,b,10.0); and Transfer(b,a,10.0); are called simultaneously the first call will lock a then the second can lock b before the first can lock a and neither can continue -> deadlock

As CodeInChaos suggests, your problem is a potential deadlock. If you don't understand what a deadlock is then I recommend reading the dining philosophers problem on Wikipedia.

The article explains the problem in real terms and suggests some solutions including using a locking order.

Edit:
To further relate your problem to the article, the bank accounts are forks (i.e. shared resources that can only be used exclusively therefore need to be locked) and the threads accessing the code are the philosophers (i.e. entities that from time to time require the use of lockable resources).

@RatchetFreak hit the nail on the head with his response regarding why this has occured. I think the main problem that you are having it that a lock is a very low level construct which makes it difficult to think about threading scenario's sanely.

I would recommend (if possible) to use a set of slightly higher level constructs to make life easier on yourself. Daniel Chamber's has a good light weight set of utilities for this in his library.

Imagine two very stubborn ladies went to a holiday house with their husbands. They woke the next morning and found the men gone. The only clothes left: a skirt and a shirt (seems one of the men liked wearing women's clothing - could explain a lot). The ladies realise the need to go get stuff - food, clothes, new husbands. They both think "well, I'll put the clothes on and go", and one puts on the skirt while the other dons the shirt. They see what's happened but each is too stubborn to change their plan (and way too shy to go out half naked). Their stubbornness is akin to a dumb computer following a program that "looked good at the time". They can't/won't automatically revise the seemingly sensible approach they had above on hitting a "run-time error", so they are both doomed to starve to death. That's a dead lock: waiting for resources you can't get because someone's waiting for what you're hogging yourself.

With a bit more foresight and planning, they could have found a strategy that would make sure one of them got out. For example:

• order based on the objects being sought:
  • e.g. only when you've already got the skirt can you take the shirt (at least with locks, one of two threads contesting it is guanteed to get it without ripping it in two), OR
• order based on the would-be owners:
  • if both want to go out at the same time, whoever's birthday is earlier can go first, or if the same then whoever's taller etc, OR
• both strip again and try after a short but random interval

etc.