This section outlines for which types of mutable Common Lisp object access is atomic. That is, each value read from the object will correspond to the state at some point in time. Note however, that if several values are read, there is no guarantee about how these values will relate to each other if they are being modified by another thread (see Issues with order of memory accesses).
When one of these mutable atomic objects is modified, readers see either the old or new value (not something else), and it is guaranteed that the Lisp image is not corrupted by the modification even if multiple threads read or write the object simultaneously.
Access to conses, simple arrays, symbols, packages and structures is atomic. Note that this does not apply to non-simple arrays.
Slot access in objects of type
standard-object
is atomic with respect to modification of the slots and and with respect to class redefinition.
vector-pop
,
vector-push
,
vector-push-extend
,
(setf fill-pointer)
and
adjust-array
are all atomic with respect to each other, and with respect to other access to the array elements.
The Common Lisp functions that access hash tables are atomic with respect to each other. See also modify-hash for atomic reading and writing an entry and with-hash-table-locked.
Note that pathnames cannot be modified, and therefore access to them is always atomic.
Operations on editor buffers (including points) are atomic and thread-safe as long as their arguments are valid. This includes modification to the text. However, buffers and points may become invalid because of execution on another thread. The macros
editor:with-buffer-locked
and
editor:with-point-locked
should be used around editor operations on buffers and points that may be affected by other processes. Note that this is applicable also to operations that do not actually modify the text, because they can behave inconsistently if the buffer they are looking at changes during the operation. See the
LispWorks Editor User Guide
for details of these macros.