If it is what I think it is, it is a topic for multithreading. A lock in the multithreading world is an object that is used to guarantee exclusive access to a piece of code or memory to a single thread, and while the lock is held by the thread, you are guaranteed no other threads are meddling with it.
Windows locks are recursive, so the same thread can lock the lock multiple times without deadlocking. I searched the web and I found an article from a guy that talks pretty strongly against recursive locks (
http://www.fieryrobot.com/blog/2008/10/14/recursive-locks-will-kill-you/ ), but I can assure you that they are no problem to me because I handle them appropriately.
Specifically, I have a C++ class called CPairTracker. This class has an internal count and two methods: Increase() and Decrease(). Then I have different classes for different types of locks (mutex, semaphore, critical section). Each of these classes inherit from CPairTracker. Whenever the Lock() method of the specialized class is called, the count is increased using Increase(); whenever the lock is unlocked the count is decreased. If the count is decreased down to a negative number an exception is thrown; when the object is destroyed, the destructor ensures the count is zero and if it isn't, then Unlock() is called as many times as necessary to reduce the count to zero. This ensures me error-free operation of the recursive lock.
So in conclusion, I don't support the idea of recursive locks being the devil because I know how to properly use them.