From 11c6f1686cf2d96c54d16713ebae7008901fa99f Mon Sep 17 00:00:00 2001 From: Matthew Flatt Date: Fri, 27 Sep 2019 10:46:21 -0600 Subject: [PATCH] reference: describe ordering guarantees for futures & places --- .../scribblings/reference/eval-model.scrbl | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/pkgs/racket-doc/scribblings/reference/eval-model.scrbl b/pkgs/racket-doc/scribblings/reference/eval-model.scrbl index 32a9e4a5e4..33344b07e3 100644 --- a/pkgs/racket-doc/scribblings/reference/eval-model.scrbl +++ b/pkgs/racket-doc/scribblings/reference/eval-model.scrbl @@ -952,8 +952,7 @@ used only to abort to the point of capture. Racket supports multiple @deftech{threads} of evaluation. Threads run concurrently, in the sense that one thread can preempt another without its cooperation, but threads currently all run on the same processor -(i.e., the same underlying operating system process and thread). See also -@secref["futures"] and @secref["places"]. +(i.e., the same underlying operating system process and thread). Threads are created explicitly by functions such as @racket[thread]. In terms of the evaluation model, each step in evaluation @@ -1001,6 +1000,21 @@ for the cell in the created thread. For a non-preserved thread cell, a new thread sees the same initial value (specified when the thread cell is created) as all other threads. +@tech{Futures} and @tech{places} offer different kinds of concurrency +and parallelism, and they have weaker guarantees about shared state. +(Places can share state through functions like +@racket[make-shared-bytes].) Each thread of evaluation in a future or +place is constrained to behave consistent with the possibility of some +other thread that might inspect any shared data starting at any point +that a future or place starts. In the case that two futures or two +places share state, each read or write operation to shared state +corresponds to a read or write operation at the virtual-memory level, +and the operations are constrained to the order they could be observed +by other threads. However, Racket does not enforce additional +guarantees about reordering that might be performed at the +virtual-memory level or below, except in the case of operations that +specify such guarantees explicitly (e.g., @racket[box-cas!]). + @;------------------------------------------------------------------------ @section[#:tag "parameter-model"]{Parameters}