how to obtain a lock in two places but release on one place?

Question

i'm newbie in c#. I need to obtain lock in 2 methods, but release in one method. Will that work?

public void obtainLock() {
    Monitor.Enter(lockObj);
}

public void obtainReleaseLock() {
    lock (lockObj) {
        doStuff
    }
}

Especially can I call obtainLock and then obtainReleaseLock? Is "doubleLock" allowed in C#? These two methods are always called from the same thread, however lockObj is used in another thread for synchronization.

upd: after all comments what do you think about such code? is it ideal?

public void obtainLock() {
    if (needCallMonitorExit == false) {
        Monitor.Enter(lockObj);
        needCallMonitorExit = true;
    }
    // doStuff
}

public void obtainReleaseLock() {
    try {
        lock (lockObj) {
            // doAnotherStuff
        }
    } finally {
        if (needCallMonitorExit == true) {
            needCallMonitorExit = false;
            Monitor.Exit(lockObj);
        }
    }
}

Answer 1

Yes, locks are "re-entrant", so a call can "double-lock" (your phrase) the lockObj. however note that it needs to be released exactly as many times as it is taken; you will need to ensure that there is a corresponding "ReleaseLock" to match "ObtainLock".

I do, however, suggest it is easier to let the caller lock(...) on some property you expose, though:

 public object SyncLock { get { return lockObj; } }

now the caller can (instead of obtainLock()):

lock(something.SyncLock) {
     //...
}

much easier to get right. Because this is the same underlying lockObj that is used internally, this synchronizes against either usage, even if obtainReleaseLock (etc) is used inside code that locked against SyncLock.

---

With the context clearer (comments), it seems that maybe Wait and Pulse are the way to do this:

void SomeMethodThatMightNeedToWait() {
    lock(lockObj) {
        if(needSomethingSpecialToHappen) {
            Monitor.Wait(lockObj);
            // ^^^ this ***releases*** the lock (however many times needed), and
            // enters the pending-queue; when *another* thread "pulses", it
            // enters the ready-queue; when the lock is *available*, it
            // reacquires the lock (back to as many times as it held it 
            // previously) and resumes work
        }
        // do some work, happy that something special happened, and
        // we have the lock
    }
}
void SomeMethodThatMightSignalSomethingSpecial() {
    lock(lockObj) {
        // do stuff
        Monitor.PulseAll(lockObj);
        // ^^^ this moves **all** items from the pending-queue to the ready-queue
        // note there is also Pulse(...) which moves a *single* item
    }
}

Note that when using Wait you might want to use the overload that accepts a timeout, to avoid waiting forever; note also it is quite common to have to loop and re-validate, for example:

lock(lockObj) {
    while(needSomethingSpecialToHappen) {
        Monitor.Wait(lockObj);
        // at this point, we know we were pulsed, but maybe another waiting
        // thread beat us to it! re-check the condition, and continue; this might
        // also be a good place to check for some "abort" condition (and
        // remember to do a PulseAll() when aborting)
    }
    // do some work, happy that something special happened, and we have the lock
}

Answer 2

Only one owner can hold the lock at a given time; it is exclusive. While the locking can be chained the more important component is making sure you obtain and release the proper number of times, avoiding difficult to diagnose threading issues.

When you wrap your code via lock { ... }, you are essentially calling Monitor.Enter and Monitor.Exit as scope is entered and departed.

When you explicitly call Monitor.Enter you are obtaining the lock and at that point you would need to call Monitor.Exit to release the lock.

Answer 3

You would have to use the Monitor for this functionality. Note that you open yourself up to deadlocks and race conditions if you aren't careful with your locks and having them taken and released in seperate areas of code can be risky

 Monitor.Exit(lockObj);

Answer 4

This doesn't work.

The code

lock(lockObj)
{
    // do stuff
}

is translated to something like

Monitor.Enter(lockObj)
try
{
    // do stuff
}
finally
{
    Monitor.Exit(lockObj)
}

That means that your code enters the lock twice but releases it only once. According to the documentation, the lock is only really released by the thread if Exit was called as often as Enter which is not the case in your code.
Summary: Your code will not deadlock on the call to obtainReleaseLock, but the lock on lockObj will never be released by the thread. You would need to have an explicit call to Monitor.Exit(lockObj), so the calls to Monitor.Enter matches the number of calls to Monitor.Exit.