Swift
-public init() {}public init()Initializes a new ReadWriteCoordinator instance.
Initializes a new ReadWriteCoordinator instance.
Initializes a new ReadWriteCoordinator instance.
Initializes a new ReadWriteCoordinator instance.
:param: queueName The name for the Grand Central Dispatch queue that
- will be created for the new ReadWriteCoordinator.
ReadWriteCoordinator.
Swift
-public init() {}public init()Initializes a new ReadWriteCoordinator instance.
Initializes a new ReadWriteCoordinator instance.
Initializes a new ReadWriteCoordinator instance.
Initializes a new ReadWriteCoordinator instance.
:param: queueName The name for the Grand Central Dispatch queue that
- will be created for the new ReadWriteCoordinator.
ReadWriteCoordinator.
CleanroomConcurrency provides:
@@ -87,13 +87,13 @@The async function provides a simple notation for specifying that a block of code should be executed asynchronously.
async takes as a parameter a no-argument function returning Void, and is typically invoked with a closure:
async {
+async {
println("This will execute asynchronously")
}
The operation specified by the closure—the println() call above—will be executed asynchronously.
-async with delay
+async with delay
A variation on the async function takes a delay parameter, an NSTimeInterval value specifying the minimum number of seconds to wait before asynchronously executing the closure:
async(delay: 0.35) {
@@ -115,7 +115,7 @@
The notation above ensures that the rootViewController is changed only on the main thread.
-mainThread with delay
+mainThread with delay
As with the async function, a variation of the mainThread function takes a delay parameter:
mainThread(delay: 0.35) {
@@ -139,7 +139,7 @@
Barrier operations are submitted for eventual execution using the notation:
-asyncBarrier {
+asyncBarrier {
println("When this executes, no other operations will be executing")
}
@@ -154,7 +154,7 @@
CriticalSections are a form of a mutex (or mutual exclusion) lock: when one thread is executing code within a given critical section, it is guaranteed that no other thread will be executing within the same instance.
In this way, CriticalSections are similar to @synchronized blocks in Objective-C.
-Using a CriticalSection
+Using a CriticalSection
With a CriticalSection, any code inside the execute closure (shown below as the `// code to execute`
comment) is executed only after exclusive access to the critical section has been acquired by the calling thread.
let cs = CriticalSection()
@@ -185,7 +185,7 @@
If exclusive access to the critical section cs can’t be acquired within 1.0 seconds, nothing will be executed and executeWithTimeout() will return false.
Note: It is best to design your implementation to avoid the potential for a deadlock. However, sometimes this is not possible, which is why the executeWithTimeout() function is provided.
-Implementation Details
+Implementation Details
The CriticalSection implementation uses an NSRecursiveLock internally, which enables CriticalSections to be re-entrant. This means that a thread can’t deadlock on a CriticalSection it already holds.
@@ -285,7 +285,7 @@
Regardless of whether a ThreadLocalValue uses a namespace, the key used to access the threadDictionary is always available via the fullKey property.
-Thread-local caching
+Thread-local caching
ThreadLocalValue instances can also be used to treat thread-local storage as a lockless cache.
@@ -317,7 +317,7 @@
CleanroomConcurrency provides:
@@ -87,13 +87,13 @@The async function provides a simple notation for specifying that a block of code should be executed asynchronously.
async takes as a parameter a no-argument function returning Void, and is typically invoked with a closure:
async {
+async {
println("This will execute asynchronously")
}
The operation specified by the closure—the println() call above—will be executed asynchronously.
-async with delay
+async with delay
A variation on the async function takes a delay parameter, an NSTimeInterval value specifying the minimum number of seconds to wait before asynchronously executing the closure:
async(delay: 0.35) {
@@ -115,7 +115,7 @@
The notation above ensures that the rootViewController is changed only on the main thread.
-mainThread with delay
+mainThread with delay
As with the async function, a variation of the mainThread function takes a delay parameter:
mainThread(delay: 0.35) {
@@ -139,7 +139,7 @@
Barrier operations are submitted for eventual execution using the notation:
-asyncBarrier {
+asyncBarrier {
println("When this executes, no other operations will be executing")
}
@@ -154,7 +154,7 @@
CriticalSections are a form of a mutex (or mutual exclusion) lock: when one thread is executing code within a given critical section, it is guaranteed that no other thread will be executing within the same instance.
In this way, CriticalSections are similar to @synchronized blocks in Objective-C.
-Using a CriticalSection
+Using a CriticalSection
With a CriticalSection, any code inside the execute closure (shown below as the `// code to execute`
comment) is executed only after exclusive access to the critical section has been acquired by the calling thread.
let cs = CriticalSection()
@@ -185,7 +185,7 @@
If exclusive access to the critical section cs can’t be acquired within 1.0 seconds, nothing will be executed and executeWithTimeout() will return false.
Note: It is best to design your implementation to avoid the potential for a deadlock. However, sometimes this is not possible, which is why the executeWithTimeout() function is provided.
-Implementation Details
+Implementation Details
The CriticalSection implementation uses an NSRecursiveLock internally, which enables CriticalSections to be re-entrant. This means that a thread can’t deadlock on a CriticalSection it already holds.
@@ -285,7 +285,7 @@
Regardless of whether a ThreadLocalValue uses a namespace, the key used to access the threadDictionary is always available via the fullKey property.
-Thread-local caching
+Thread-local caching
ThreadLocalValue instances can also be used to treat thread-local storage as a lockless cache.
@@ -317,7 +317,7 @@