Object locks

In some cases, the system acquires object locks on behalf of actions a user takes against certain objects. The system respects and enforces object locks for some actions.

You can acquire object locks such that the lock is effective only within the thread (thread-scoped) or is effective within the process (process-scoped). If two threads in the same process each try to acquire a process-scoped lock to a system object, that lock is satisfied for both threads. Neither thread prevents the other from acquiring the lock if they are in the same process.

If you are using object locks to protect access to an object from two threads within the same process, you should use object locks that are scoped to a thread. A thread-scoped object lock never conflicts with an object lock scoped to a process that is acquired by the same process.

Object locks allow an application to coordinate the use of different locking request types. More than one thread can acquire a shared but thread-scoped lock on the same system object. Your application can also acquire different types of object locks in a way that is similar to space locks. This allows more than one thread to acquire a thread-scoped shared lock on a single target.

Because extra lock types are provided by object locks, the concept of an owner is slightly different than it is with mutual exclusions (mutexes). There can be multiple owners of a shared, thread-scoped lock. If each owner has successfully acquired the shared thread-scoped lock, all of the shared locks must be unlocked for a thread to get an exclusive thread-scoped object lock.