Most of the bindings described in this section are part of the
structure--the low-level bindings described at the very end of the
section are part of the
proposal is a record of reads from and and writes to locations in
memory. Each thread has an associated current proposal
(which may be
logging operations listed below record any values read or
written in the current proposal.
A reading operation, such as
provisional-vector-ref, first checks to
see if the current proposal contains a value for the relevent location.
If so, that value is returned as the result of the read.
If not, the current contents of the location are stored in the proposal and
then returned as the result of the read.
A logging write to a location stores the new value as the current contents of
the location in the current proposal; the contents of the location itself
Committing to a proposal verifies that any reads logged in
the proposal are still valid and, if so, performs any writes that
the proposal contains.
A logged read is valid if, at the time of the commit, the location contains
the same value it had at the time of the original read (note that this does
not mean that no change occured, simply that the value now is the same as
the value then).
If a proposal has an invalid read then the effort to commit fails; no change
is made to the value of any location.
The verifications and subsequent writes to memory are performed atomically
with respect to other proposal commit attempts.
(call-ensuring-atomicity thunk) -> value ...
call-ensuring-atomicity!simply make a (tail-recursive) call to
thunk. If the current proposal is
#fthey create a new proposal, install it, call
thunk, and then try to commit to the proposal. This process repeats, with a new proposal on each iteration, until the commit succeeds.
Call-ensuring-atomicityreturns whatever values are returned by
thunkon its final invocation, while
ensure-atomicity!discards any such values and returns nothing.
ensure-atomicity! are macro versions of
(ensure-atomicity expands into
(call-ensuring-atomicity (lambda () ; likewise for
(provisional-car pair) -> value
(provisional-cdr pair) -> value
(provisional-set-car! pair value)
(provisional-set-cdr! pair value)
(provisional-cell-ref cell) -> value
(provisional-cell-set! cell value)
(provisional-vector-ref vector i) -> value
(provisional-vector-set! vector i value)
(provisional-string-ref vector i) -> char
(provisional-string-set! vector i char)
(provisional-byte-vector-ref vector i) -> k
(provisional-byte-vector-set! vector i k)
#fthese perform exactly as their Scheme counterparts.
The following implementation of a simple counter may not function properly when used by multiple threads.
(define (make-counter) (let ((value 0)) (lambda () (set! value (+ value 1)) value)))
Here is the same procedure using a proposal to ensure that each increment operation happens atomically. The value of the counter is kept in a cell to allow the use of logging operations.
(define (make-counter) (let ((value (make-cell 0))) (lambda () (ensure-atomicity (lambda () (let ((v (+ (provisional-cell-ref value) 1))) (provisional-cell-set! value v) v))))))
ensure-atomicity creates a new proposal only if there is
no existing proposal in place, multiple atomic actions can be merged
into a single atomic action.
For example, the following procedure increments an arbitrary number of
counters at the same time.
This works even if the same counter appears multiple times;
(step-counters! c0 c0) would add two to the value of counter
(define (step-counters! . counters) (ensure-atomicity (lambda () (for-each (lambda (counter) (counter)) counters))))
This is the same as(define-synchronized-record-type
define-record-typeexcept all field reads and writes are logged in the current proposal. If the optional list of field tags is present then only those fields will be logged.
(call-atomically thunk) -> value(s)
call-atomically!are identical to
call-ensuring-atomicity!except that they always install a new proposal before calling
thunk. The current proposal is saved and then restored after
Call-atomically!are useful if
thunkcontains code that is not to be combined with any other operation.
atomically! are macro versions of
(atomically expands into
(call-atomically (lambda () ; likewise for
With-new-proposal saves the current proposal, installs a new
one, executes the forms in the body, and returns whatever they
returns. It also binds
lose to a thunk repeating the
procedure of installing a new procedure and running the body.
Typically, the body will call
maybe-commit and, if that fails,
lose to try again.
The following procedures give access to the low-level proposal
mechanism. They are defined in the
(maybe-commit) -> boolean
(make-proposal) -> proposal
(current-proposal) -> proposal
Maybe-commitverifies that any reads logged in the current proposal are still valid and, if so, performs any writes that it contains. A logged read is valid if, at the time of the commit, the location read contains the same value it had at the time of the original read (note that this does not mean that no change occured, simply that the value now is the same as the value then).
#tif the commit succeeds and
#fif it fails.
Make-proposal creates a new proposal.
set-current-proposal access and set
the current thread's proposal.
It is an error to pass to
set-current-proposal! a proposal that
is already in use.
Previous: Optimistic concurrency | Next: Optimistic concurrency