o The lock space pointer itself must at all times be either NULL or point to a valid lock space struct, since another thread need to access it to tell whether access to the thing is permissible. A write lock is required to change the lock space pointer, but even so the update must be atomic. Since the lock space lock structs are collected by the gc, there is no risk for races when threads asynchronously dereference lock space pointers.
pointers in any thing, regardless
of its locks. That does however not imply that all pointer updates
atomic: If a pointer gets updated by the locking thread
then the old value gets logged first (c.f. issue "Garbage collector",
item d). The gc checks after reading the pointer from the live thing
if it has been logged, and if so then the logged value is used
instead. Hence the gc never uses the value read from the live thing if
it could have gotten updated concurrenty.
Issue: Lock space locking This is the locking procedure to access a thing: 1. Read the lock space pointer. If it's NULL then the thing is thread local and nothing more needs to be done. 2. Address an array containing the pointers to the lock spaces that are already locked by the thread.