This class extends class ThreadLock, adding functionality to register 'acquirers' of type ThreadLock. Only with the second acquirer added, the lock is activated using ThreadLock.SetSafeness(Safeness.Safe). The goal is to not use a mutex, when such use is not needed. In occasions with very high frequency of acquisition, this can provide a performance benefit.
The following rules apply:
- An instance of this type must not be acquired before an acquirer is registered.
- The acquirers have to be in recursive mode.
- If acquirers are locked in a nested fashion, then they have to be added in the same order they are locked and removed in reverse order
- An acquirer must not be added twice. (This is not a technical restriction, but a chosen design. While a second addition is ignored, in debug versions of the code, an ALib Error Report is written (by default this triggers an assertion).
Using nulled acquirers:
Sometimes it is useful to add a null
as an acquirer. A sample for this is found and explained with lib.ALIB.StdOutputStreamsLock. If the first acquirer is null, the second should be added in a thread-safe way. This means, the code invoking AddAcquirer needs to care for itself, that this object is not acquired during this process. E.g. it can be done in the bootstrap section of a process, when no parallel threads were started. For further acquirere, such care does not need to be taken. While an acquirer must not be attached twice, 'anonymous' (null) acquirers may. For each anonymous invocation of AddAcquirer, a corresponding call RemoveAcquirer is needed, to get back to Safeness.Unsafe.