pike.git / multi-cpu.txt

version» Context lines:

pike.git/multi-cpu.txt:327:   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.    - FIXME: What about concurrent gc access to follow pointers? + Note: The gc might concurrently read pointers in any thing, regardless + of its locks. That does however not imply that all pointer updates + have to be 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.