Copyright ã1994 by NeXT Computer, Inc.  All Rights Reserved.

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 objectsÐexcept for NSConditionLock objectsÐcontain 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.