RE: Pre-emptive or co-operative concurrency (was: Concurrency)
On 29 March 2006 17:21, Claus Reinke wrote:
all of the concurrency implementations discussed so far seem to be based on a mixture of preemptive and non-premptive scheduling. context-switches happen only on specific events, which every thread will usually engage in, although it need not always do so:
1 only calls to yield 2 any calls to concurrency library api 3 any allocation
Not true - in GHC with SMP a thread doing no allocation can be running concurrently with any number of other threads. It's only the single-threaded implementation that has this bug where a thread that doesn't allocate can starve the other threads. In fact, even on a uniprocessor, you can use GHC's SMP mode to work around the bug by pretending you have 2 CPUs. GHC's SMP mode is truly preemptive, operations from multiple threads can be arbitrarily interleaved. So let's stop saying that all known implementations are non-preemptive, please ;-) Cheers, Simon
On Thu, Mar 30, 2006 at 10:54:01AM +0100, Simon Marlow wrote:
Not true - in GHC with SMP a thread doing no allocation can be running concurrently with any number of other threads. It's only the single-threaded implementation that has this bug where a thread that doesn't allocate can starve the other threads. In fact, even on a uniprocessor, you can use GHC's SMP mode to work around the bug by pretending you have 2 CPUs.
it should be noted that I don't consider this a bug, but a design choice. of course, since you made the choice differently then for GHC it is a bug :)
GHC's SMP mode is truly preemptive, operations from multiple threads can be arbitrarily interleaved. So let's stop saying that all known implementations are non-preemptive, please ;-)
well, as preemptive as the pthreads implementation at least. which is usually very, but not so with some userspace implementations of pthreads. Both are allowed by the standard so "counting" on preemption is a bad idea in general, even with ghc. (though, perhaps this isn't true, ghc has its own mini-threads underneath OS threads in -threaded mode if I understand it properly and that makes things less simplistic.) however, this is all just reiteration of the "never count on the scheduler" rule when writing threaded apps when you didn't write the operating system :) (hard real-time bug-free systems exempt) John -- John Meacham - ⑆repetae.net⑆john⑈
GHC's SMP mode is truly preemptive, operations from multiple threads can be arbitrarily interleaved. So let's stop saying that all known implementations are non-preemptive, please ;-)
but gladly, if that is the default!-) so if we take that hypothetical example of foreign exporting GHC's concurrency support, can we assume that the (IO a)s implemented in foreign code will be given their own OS thread when using that concurrency library? all of them, or only the non-atomic ones? if, say, Hugs was to foreign import that library from GHC, its IO actions wouldn't do much (GHC-side )allocation; and if Hugs was to import that same library from YHC, it wouldn't do many (YHC-side) abstract machine steps; etc.; we could try real time-slicing, but how would we suspend/restart foreign code? so there doesn't seem to be much choice for integrating foreign IO code into the schedule, other than giving it its own OS-thread; of course, Hugs' IO actions may not be thread-safe, so that may not be an option, either. the point being: the FFI says something about how to integrate foreign and Haskell memory management; should it also say something about threadability of foreign code (wrt to scheduling, and wrt thread-safety)? cheers, claus ps: Neil said:
If all Haskell' prime implementations depend on "GHC the library", then do we really have many Haskell' prime implementations, or just a pile of wrappers around GHC?
are you implying that implementing external libraries in Haskell is in any way inferior to implementing them in C?-)
participants (3)
-
Claus Reinke -
John Meacham -
Simon Marlow