Do threads support SMP?
[email protected] (Steven W McDougall) Fri, 18 Aug 2000 11:32:59 -0400 (EDT)
| Newsgroups | perl.perl6.language.flow |
|---|---|
| Message-ID | <[email protected]> |
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