pike.git / multi-cpu.txt

version» Context lines:

pike.git/multi-cpu.txt:37:   2. There should be as few internal hot spots as possible (preferably    none) when pike code is executed concurrently. Care must be taken    to avoid internal synchronization, or updates of shared data that    would cause "cache line ping-pong" between cpus.      3. The concurrency should be transparent on the pike level. Pike code    should still be able to access shared data without locking and    without risking low-level inconsistencies. (So Thread.Mutex etc    would still be necessary to achieve higher level synchronization.)    - 4. There should be tools on the pike level to allow further + 4. Current pike code should continue to run without compatibility +  problems, and also keep the same time and space complexity +  characteristics in the uniprocessor or locked case. This includes +  important optimizations that defines de-facto behavior which much +  pike code takes into account. +  + 5. There should be tools on the pike level to allow further    performance tuning, e.g. lock-free queues, concurrent access hash    tables, and the possibility to lock different regions of shared    data separately. These tools should be designed so that they are    easy to slot into existing code with few changes.    - 5. There should be tools to monitor and debug concurrency. It should + 6. There should be tools to monitor and debug concurrency. It should    be possible to make assertions that certain objects aren't shared,    and that certain access patterns don't cause thread    synchronization. This is especially important if goal (3) is    realized, since the pike code by itself won't show what is shared    and what is thread local.    - 6. C modules should continue to work without source level + 7. C modules should continue to work without source level    modification (but likely without allowing any kind of    concurrency).      Note that even if goal (3) is accomplished, this is no miracle cure   that would make all multithreaded pike programs run with optimal   efficiency on multiple cpus. One could expect better concurrency in   old code without adaptions, but it could still be hampered   considerably by e.g. frequent updates to shared data. Concurrency is a   problem that must be taken into account on all levels.