pike.git/
multi-cpu.txt
Branch:
Tag:
Non-build tags
All tags
No tags
2010-10-05
2010-10-05 22:46:22 by Martin Stjernholm <mast@lysator.liu.se>
5be49ba5092b837fd99cc9b1634fdc803bc32d93 (
13
lines) (+
10
/-
3
)
[
Show
|
Annotate
]
Branch:
mast/multi-cpu
State compatibility as a goal.
44:
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).