► |  | The Racket Reference

1 | Language Model
2 | Syntactic Forms
3 | Datatypes
4 | Structures
5 | Classes and Objects
6 | Units
7 | Contracts
8 | Pattern Matching
9 | Control Flow
10 | Concurrency and Parallelism
11 | Macros
12 | Input and Output
13 | Reflection and Security
14 | Operating System
15 | Memory Management
16 | Unsafe Operations
17 | Running Racket
| Bibliography
| Index

▼ | 10 | Concurrency and Parallelism

10.1 | Threads
10.2 | Synchronization
10.3 | Thread-Local Storage
10.4 | Futures
10.5 | Futures Visualizer
10.6 | Futures Tracing
10.7 | Places
10.8 | Distributed Places

On this page:

future
touch
futures-enabled?
current-future
future?
would-be-future
processor-count
make-fsemaphore
fsemaphore?
fsemaphore-post
fsemaphore-wait
fsemaphore-try-wait?
fsemaphore-count

top← prev up next →

#### 10.4`` Futures

> > > Parallelism with Futures in The Racket Guide introduces futures.

(require racket/future)

The bindings documented in this section are provided by the racket/future and racket libraries, but not racket/base.

> > > Currently, parallel support for future is enabled by default for Windows, Linux x86/x86_64, and Mac OS X x86/x86_64. To enable support for other platforms, use --enable-futures with configure when building Racket.

The future and touch functions from racket/future provide access to parallelism as supported by the hardware and operating system. In contrast to thread, which provides concurrency for arbitrary computations without parallelism, future provides parallelism for limited computations. A future executes its work in parallel (assuming that support for parallelism is available) until it detects an attempt to perform an operation that is too complex for the system to run safely in parallel. Similarly, work in a future is suspended if it depends in some way on the current continuation, such as raising an exception. A suspended computation for a future is resumed when touch is applied to the future.

“Safe” parallel execution of a future means that all operations provided by the system must be able to enforce contracts and produce results as documented. “Safe” does not preclude concurrent access to mutable data that is visible in the program. For example, a computation in a future might use set! to modify a shared variable, in which case concurrent assignment to the variable can be visible in other futures and threads. Furthermore, guarantees about the visibility of effects and ordering are determined by the operating system and hardware—which rarely support, for example, the guarantee of sequential consistency that is provided for thread-based concurrency. At the same time, operations that seem obviously safe may have a complex enough implementation internally that they cannot run in parallel. See also Parallelism with Futures in The Racket Guide.

A future never runs in parallel if all of the custodians that allow its creating thread to run are shut down. Such futures can execute through a call to touch, however.

> procedure (future thunk) → future?
> thunk : (-> any)
> procedure (touch f) → any
> f : future?

The future procedure returns a future value that encapsulates thunk. The touch function forces the evaluation of the thunk inside the given future, returning the values produced by thunk. After touch forces the evaluation of a thunk, the resulting values are retained by the future in place of thunk, and additional touches of the future return those values.

Between a call to future and touch for a given future, the given thunk may run speculatively in parallel to other computations, as described above.

> > (let ([f (future (lambda () (+ 1 2)))])
> (list (+ 3 4) (touch f)))
> '(7 3)

> procedure (futures-enabled?) → boolean?

Returns whether parallel support for futures is enabled in the current Racket configuration.

> procedure (current-future) → (or/c #f future?)

Returns the descriptor of the future whose thunk execution is the current continuation. If a future thunk itself uses touch, future-thunk executions can be nested, in which case the descriptor of the most immediately executing future is returned. If the current continuation is not a future-thunk execution, the result is #f.

> procedure (future? v) → boolean?
> v : any/c

Returns #t if v is a future value, #f otherwise.

> procedure (would-be-future thunk) → future?
> thunk : (-> any)

Returns a future that never runs in parallel, but that consistently logs all potentially “unsafe” operations during the execution of the future’s thunk (i.e., operations that interfere with parallel execution).

With a normal future, certain circumstances might prevent the logging of unsafe operations. For example, when executed with debug-level logging,

> (touch (future (lambda ()
> (printf "hello1")
> (printf "hello2")
> (printf "hello3"))))

might log three messages, one for each printf invocation. However, if the touch is performed before the future has a chance to start running in parallel, the future thunk evaluates in the same manner as any ordinary thunk, and no unsafe operations are logged. Replacing future with would-be-future ensures the logging of all three calls to printf.

> procedure (processor-count) → exact-positive-integer?

Returns the number of parallel computation units (e.g., processors or cores) that are available on the current machine.

> procedure (make-fsemaphore init) → fsemaphore?
> init : exact-nonnegative-integer?

Creates and returns a new future semaphore with the counter initially set to init.

A future semaphore is similar to a plain semaphore, but future-semaphore operations can be performed safely in parallel (to synchronize parallel computations). In contrast, operations on plain semaphores are not safe to perform in parallel, and they therefore prevent a computation from continuing in parallel.

> procedure (fsemaphore? v) → boolean?
> v : any/c

Returns #t if v is an future semaphore value, #f otherwise.

> procedure (fsemaphore-post fsema) → void?
> fsema : fsemaphore?

Increments the future semaphore’s internal counter and returns #<void>.

> procedure (fsemaphore-wait fsema) → void?
> fsema : fsemaphore?

Blocks until the internal counter for fsema is non-zero. When the counter is non-zero, it is decremented and fsemaphore-wait returns #<void>.

> procedure (fsemaphore-try-wait? fsema) → boolean?
> fsema : fsemaphore?

Like fsemaphore-wait, but fsemaphore-try-wait? never blocks execution. If fsema’s internal counter is zero, fsemaphore-try-wait? returns #f immediately without decrementing the counter. If fsema’s counter is positive, it is decremented and #t is returned.

> procedure (fsemaphore-count fsema) → exact-nonnegative-integer?
> fsema : fsemaphore?

Returns fsema’s current internal counter value.
top← prev up next →