views:

150

answers:

3

I have a situation where a block of code should be executed only if two locker objects are free.

I was hoping there would be something like:

lock(a,b)
{
    // this scope is in critical region
} 

However, there seems to be nothing like that. So does it mean the only way for doing this is:

lock(a)
{
    lock(b)
    {
        // this scope is in critical region
    }
}

Will this even work as expected? Although the code compiles, but I am not sure whether it would achieve what I am expecting it to.

+7  A: 

Requesting the lock on both should work fine. lock(a) will block until a is free. Once you have that lock, lock(b) will block until you have b. After that you have both.

One thing you need to be very careful about here is the order. If you're going to do this make sure you always get the lock on a before getting the lock on b. Otherwise you could very easily find yourself in a deadlock situation.

Herms
+2  A: 

I'd expect it to, though there'd be a case where it could potentially cause a deadlock condition.

Normally, the code will attempt to lock a and then proceed to lock b if that succeeded. This means that it would only execute the code if it could lock both a and b. Which is what you want.

However, if some other code has already got a lock on b then this code will not do what you expect. You'd also need to ensure that everywhere you needed to lock on both a and b you attempt to get the locks in the same order. If you get b first and then a you would cause a deadlock.

ChrisF
Actually it will not fail if something else has a lock on b - it will wait until that is released.
TomTom
@TomTom: If the other thread just tries to access one of the locks, then we won't have any problem, but if it tries to lock both a and b and in reverse order, there is good chance for deadlock.@ChrisF: Are they outer curly braces necessary in your edit, or you did this just to make code look cleaner?
Gunner
@Gunner - just an attempt to make the code look cleaner and clarify the scope of the lock. Hope that's OK.
ChrisF
@ChrisF: Ah it's ok. I guess these lock scopes work just like other scoping contexts. For example, in many cases of nested for loop, we usually don't place curly braces for the outer loop.
Gunner
@Gunner - yes, ultimately just a matter of coding style, but I feel it adds a little bit of clarity when viewing code outside an IDE where you don't have the tools to help you.
ChrisF
+5  A: 
lock(a) lock(b) { // this scope is in critical region }

This could would block until the thread can acquire the lock for a. Then, with that lock acquired, it would block until the thread can acquire the lock for b. So this works as expected.

However, you have to be careful not to do this somewhere else:

lock(b) lock(a) { // this scope is in critical region }

This could lead to a deadlock situation in which thread 1 has acquired the lock for a and is waiting to acquire the lock for b, and thread 2 has acquired the lock for b and is waiting to acquire the lock for a.

dtb