Does Perl6 support Symmetric MultiProcessing (SMP)?
This is a *huge* issue. It affects everything else that we do with
threads.
1 No
If Perl6 doesn't support SMP, then the interpreter can be implemented
with cooperative threads. It calls yield() internally to switch
threads, and by design, it only does so when it is in a consistent
state. Any remaining synchronization issues are, by definition, the
user's problem.
1.1 Pros
1.1.1 Implementation
Implementation is (relatively) easy. All kinds of hard problems are
finessed by not yielding at inconvenient points.
1.1.2 Performance
Performance (on your single processor) is good. The only cost to
non-threaded programs are calls to yield() that return immediately.
The only cost to threaded programs are the actual context switches,
plus any synchronization mechanisms called from user code. The
interpreter itself doesn't need any synchronization mechanisms.
1.1.3 Granularity
You don't have to worry too much about the granularity of context
switches. Since you only have one processor, the entire job won't
complete any sooner than it would without threads. As long as the
program remains reasonably responsive to the user (<100 mS response
time) it doesn't matter exactly when or where you context switch.
1.2 Cons
We don't get SMP. SMP is a nyah, nyah issue. Without SMP, Perl will
have trouble outgrowing its toy/scripting language reputation.
2 Yes
If Perl6 supports SMP, then then the interpreter gets preemptive
threads and meticulous synchronization throughout.
2.1 Pros
We get SMP. SMP is one of the reasons that people write threads in the
first place: they have a CPU-intensive program and they want to bring
multiple processors to bear on it.
2.2 Cons
2.2.1 Implementation
Implementation is *hard*. It's like pre-emptive multi-tasking, only
worse. There are N>1 processors reading and writing the same memory
locations at the same time. The hardware arbitrates use of the bus;
everything else is up to (our) software.
In general, the interpreter has to serialize access to any data
structure that could possibly be accessed by multiple threads. Race
conditions crash the interpreter, but can't be reproduced in a
deterministic way. This makes debugging in an SMP environment *very*
difficult.
2.2.2 Performance
You get multiple processors working on your problem (good), but you
have to synchronize them (bad). Global things, like the heap, tend to
become performance bottlenecks.
The interpreter will probably be crawling with critical sections. All
programs--threaded or not--pay the freight for entering and leaving
these.
2.2.3 Granularity
If you serialize access to data structures at a fine-grained level,
then you spend a lot of time entering and leaving critical sections,
acquiring and releasing mutexes, etc.
If you serialize access to data structures at a coarse-grained level,
you get Software Processor Lockout (SPL). One thread gets access to
something, settles down to work on it for a while, and the other
processors *block* waiting for access to it.
- SWM
