pike.git / multi-cpu.txt

version» Context lines:

pike.git/multi-cpu.txt:277:   o A read-safe lock ensures only that the data is consistent, not that    it stays constant. This allows lock-free updates in things where    possible (which could include arrays, mappings, and maybe even    multisets and objects of selected classes).      o A read-constant lock ensures both consistency and constantness    (i.e. what usually is assumed for a read-only lock).      o A write lock ensures complete exclusive access. The owning thread    can modify the data, and it can assume no other changes occur to it -  (barring refcounters and lock space pointers - see below). The -  owning thread can also under limited time leave the data in +  (barring refcounters and lock space pointers - see below), although +  that assumption has to be "weak" since there are a few situations +  when another thread can intervene - see issue "Emulating the +  interpreter lock". +  +  The owning thread can also under limited time leave the data in    inconsistent state. This is however still limited by the calls to    check_threads(), which means that the state must be consistent -  again every time the evaluator callbacks are run. See issue -  "Emulating the interpreter lock". +  again every time the evaluator callbacks are run. The reason is the +  same one as above.      Allowing lock-free updates is attractive, so the standard read/write   lock that governs the global lock space will probably be multiple   read-safe/single write.      The lock space lock covers all the data in the thing, with two   exceptions:      o The refcounter (and other gc-related flags and fields) can always    change concurrently since the gc runs in a thread of its own, and
pike.git/multi-cpu.txt:317:   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?    -  +    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.   3. Search for the lock space pointer in the array. If present then    nothing more needs to be done.
pike.git/multi-cpu.txt:915:      Issue: Exceptions      "Forgotten" locks after exceptions shouldn't be a problem: Explicit   locks are handled just like today (i.e. it's up to the pike   programmer), and implicit locks can safely be released when an   exception is thrown.      One case requires attention: An old-style function that requires the   compat interpreter lock might catch an error. In that case the error - system has to ensure that lock is reacquired. This is however only a - problem if C level module compatibility is kept as an option, which - currently appears to be unlikely with the proposed gc (see issue - "Garbage collector", item c). + system has to ensure that lock is reacquired.         Issue: C module interface      A new add_function variant is probably added for new-style functions.   It takes bits for the flags discussed for issue "Function calls".   New-style functions can only assume free access to the current storage   according to those flags; everything else must be locked (through a   new set of macros/functions).   
pike.git/multi-cpu.txt:1035:      Issue: Thread.Queue      A lock-free implementation should be used. The things in the queue are   typically disowned to allow them to become thread local in the reading   thread.         Issue: "Relying on the interpreter lock"    + FIXME    -  +    Issue: False sharing      False sharing occurs when thread local things used frequently by   different threads are next to each other so that they share the same   cache line. Thus the cpu caches might force frequent resynchronization   of the cache line even though there is no apparent hotspot problem on   the C level.      This can be a problem in particular for all the block_alloc pools   containing small structs. Using thread local pools is seldom a
pike.git/multi-cpu.txt:1097:   configured maximum size for as long as possible. This is more   important if the gc is used also for previously refcounted garbage   (c.f. issue "Garbage collector").      Malloc calls should be wrapped to allow the gc to run in blocking mode   in case they fail.         Issue: The compiler    + FIXME    -  +    Issue: Foreign thread visits    - JVM threads.. + FIXME. JVM threads..         Issue: Pike security system      It is possible that keeping the pike security system intact would   complicate the implementation, and even if it was kept intact a lot of   testing would be required before one can be confident that it really   works (and there are currently very few tests for it in the test   suite).   
pike.git/multi-cpu.txt:1238:      o *BSD: FIXME: Check this.         Issue: Platform specific primitives      Some low-level primitives, such as CAS and fences, are necessary to   build the various lock-free tools. A third-party library would be   useful.    - An effort to make a standardized library is here: - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2047.html (C - level interface at the end). It apparently lacks implementation, + o An effort to make a standardized library is here: +  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2047.html +  (C level interface at the end). It apparently lacks implementation,    though.    - The linux kernel is reported to contain a good abstraction lib for + o The linux kernel is reported to contain a good abstraction lib for    these primitives, along with implementations for a large set of    architectures (see    http://www.rdrop.com/users/paulmck/scalability/paper/ordering.2006.08.21a.pdf). - Can we use it? (Check GPL contamination.) +     -  + o Another one is part of a lock-free hash implementation here: +  http://www.sunrisetel.net/software/devtools/sunrise-data-dictionary.shtml +  It has a MIT-style open source license (with ad clauses). +  + It appears that the libraries themselves are very short and simple; + the difficult part is rather to specify the semantics carefully. It's + probably easiest to make one ourselves with ideas from e.g. the linux + kernel paper mentioned above. +    Required operations:      CAS(address, old_value, new_value)    Compare-and-set: Atomically sets *address to new_value iff its    current value is old_value. Needed for 32-bit variables, and on    64-bit systems also for 64-bit variables.      ATOMIC_INC(address)   ATOMIC_DEC(address)    Increments/decrements *address atomically. Can be simulated with