pike.git / multi-cpu.txt

version» Context lines:

pike.git/multi-cpu.txt:838:   specific mapping/multiset.      If mappings and/or multisets are changed to be lock-free then the   copy-on-write behavior needs to be solved:      o A flag is added to the mapping/multiset data block that is set    whenever it is shared.   o Every destructive operation checks the flag. If set, it makes a    copy, otherwise it changes the original block. Thus the flag is    essentially a read-only marker. - o The flag is cleared by the gc if it finds only one ref to a data -  block. (Refcounting cannot be used without locking.) + o In addition to the flag, the gc performs normal refcounting. It +  clears the flag if the refcount is 1. (The refcount cannot be used +  directly since it's delay-updated.)   o Hazard pointers are necessary for every destructive access,    including the setting of the flag. The reason is that the    read-onlyness only is in effect after all currently modifying    threads are finished with the block. The thread that is setting the    flag therefore has to wait until there are no other hazard pointers    to the block before returning.      It's a good question whether keeping the copy-on-write feature is   worth this overhead. Of course, an alternative is to simply let the   builtin mappings and/or multisets be locking, and instead have special   objects that implements lock-free data types.      Another issue is if things like mapping/multiset data blocks should be   first or second class things (c.f. issue "Memory object structure").   If they're second class it means copy-on-write behavior doesn't work   across lock spaces. If they're first class it means additional   overhead handling the lock spaces of the mapping data blocks, and if a   mapping data is shared between lock spaces then it has to be in some   third lock space of its own, or in the global lock space, neither of - which would be very good. + which would be very good. So it doesn't look like there's a better way + than to botch copy-on-write in this case.    - So it doesn't look like there's a better way than to botch - copy-on-write in this case. +     -  +    Issue: Emulating the interpreter lock      For compatibility with old C modules, and for the _disable_threads   function, it is necessary to retain a complete lock like the current   interpretator lock. It has to lock the global area for writing, and   also stop all access to all lock spaces, since the thread local data   might refer to any lock space.      This lock is implemented as a read/write lock, which normally is held   permanently for reading by all threads. Only when a thread is waiting