|
|
@@ -0,0 +1,95 @@
|
|
|
+* 3.4 Concurrency: Time Is of the Essence
|
|
|
+when you allow local state not only the expression matters--so does
|
|
|
+the /time/ it was executed
|
|
|
+
|
|
|
+computers are largely sequential; concurrency complicates things
|
|
|
+
|
|
|
+** 3.4.1 the nature of time in concurrent systems
|
|
|
+"time is a device that was invented to keep everything from happening
|
|
|
+at once"
|
|
|
+
|
|
|
+when multiple actions share state vars, you can have race conditions.
|
|
|
+
|
|
|
+** 3.4.2 mechanisms for controlling concurrency
|
|
|
+a practical approach for managing time is to design mechanisms that
|
|
|
+can constrain the interleaving of concurrent processes. many have been
|
|
|
+developed. one of them is the /serializer/.
|
|
|
+
|
|
|
+ - serialization :: processes execute concurrently, but there are
|
|
|
+ collections of procedures that cannot
|
|
|
+
|
|
|
+serialization creates distinguished sets of procedures such that only
|
|
|
+one procedure in a set can be executed at a time.
|
|
|
+
|
|
|
+concurrent gets much harder when there are multiple shared resources
|
|
|
+
|
|
|
+IMPLEMENTING SERIALIZERS
|
|
|
+
|
|
|
+we implement serializers with a /mutex/
|
|
|
+
|
|
|
+a mutex is an object that supports two operations:
|
|
|
+ - a mutex can be /acquired/
|
|
|
+ - a mutex can be /released/
|
|
|
+
|
|
|
+once a mutex is acquired, no one else can acquire until it's
|
|
|
+released. "mutex" stands for *mutual exclusion*.
|
|
|
+
|
|
|
+they name check dijkstra!
|
|
|
+
|
|
|
+#+BEGIN_SRC scheme
|
|
|
+ (define (make-serializer)
|
|
|
+ (let ((mutex (make-mutex)))
|
|
|
+ (lambda (p)
|
|
|
+ (define (serialized-p . args)
|
|
|
+ (mutex 'acquire)
|
|
|
+ (let ((val (apply p args)))
|
|
|
+ (mutex 'release)
|
|
|
+ val))
|
|
|
+ serialized-p)))
|
|
|
+#+END_SRC
|
|
|
+
|
|
|
+the mutex is a mutable obj that can hold true or false. when it is
|
|
|
+false, the mutex can be acquired. when it is true, the process trying
|
|
|
+to acquire the mutex must wait.
|
|
|
+
|
|
|
+#+BEGIN_SRC scheme
|
|
|
+ (define (make-mutex)
|
|
|
+ (let ((cell (list false)))
|
|
|
+ (define (the-mutex m)
|
|
|
+ (cond ((eq? m 'acquire)
|
|
|
+ (if (test-and-set! cell)
|
|
|
+ (the-mutex 'acquire))) ; retry
|
|
|
+ ((eq? m 'release) (clear! cell))))
|
|
|
+ the-mutex))
|
|
|
+
|
|
|
+ (define (clear! cell)
|
|
|
+ (set-car! cell false))
|
|
|
+
|
|
|
+ (define (test-and-set! cell)
|
|
|
+ (if (car cell)
|
|
|
+ true
|
|
|
+ (begin (set-car! cell true)
|
|
|
+ false)))
|
|
|
+#+END_SRC
|
|
|
+
|
|
|
+this implementation of test-and-set! is insufficient. see text for
|
|
|
+details.
|
|
|
+
|
|
|
+DEADLOCK
|
|
|
+
|
|
|
+if you try to switch A with B
|
|
|
+while someone else tries to switch B with A
|
|
|
+you might get a deadlock, where A is waiting for B
|
|
|
+and B is waiting for A and so
|
|
|
+nothing gets done
|
|
|
+
|
|
|
+CONCURRENCY, TIME, AND COMMUNICATION
|
|
|
+
|
|
|
+it is not clear, really, what "shared state" means
|
|
|
+
|
|
|
+this "state" thing is turning out to be one big headache
|
|
|
+
|
|
|
+this shit also comes up in the Theory of Relativity
|
|
|
+
|
|
|
+these complexities of concurrency seem to reflect a fundamental
|
|
|
+complexity of the universe.
|
