NSLocking

Adopted By: NSConditionLock

NSLock

NSRecursiveLock

Declared In: Foundation/NSLock.h

Protocol Description

This protocol is used by classes that provide lock objects. The lock objects provided by OpenStep are used only for protecting critical sections of code: sections that manipulate shared data and that can be executed simultaneously in several threads. Lock objectsexcept for NSConditionLock objectscontain no useful data.

Although an object that isn't a lock could adopt the NSLocking protocol, it may be more desirable to design the object so that all locking is handled internally, through normal use rather than requiring that the object be explicitly locked and unlocked.

In order to enable clients to only have locks when processes become multithreaded, it is permissible to unlock a lock freshly created (i.e. that has not been locked)unless it is a recursive lock.

Three classes conform to the NSLocking protocol:

Class Usage

NSLock Protect critical sections of code.

NSConditionLock Protects critical sections of code, but can also be used to postpone entry to a critical section until a condition is met. This class is functionally a superset of the NSLock class, though unlocking is slightly more expensive.

NSRecursiveLock Protects critical sections from access by multiple threads, but allows a single thread to acquire a lock several times without deadlocking.

None of these classes busy-waits while the lock is unavailable. All classes may all be efficiently used for long sections of atomic code. See the class specifications for these classes for further information on their behavior and usage.

Locking Operations

- (void)lock Acquires a lock. Applications generally do this when entering a critical section of their code. A thread will sleep if it can't immediately acquire the lock.

- (void)unlock Releases a lock. Applications generally do this when exiting a critical section of their code.