I'm curious about the implementation of Concurrent Haskell in GHC and Hugs. Does access to values possibly shared among threads cost the same in Concurrent Haskell as in regular Haskell? I'm guessing the answer is "yes", because Concurrent Haskell is provided by default in GHC. If the costs are the same, does that rely on there being no true concurrency in the current implementations? How would the cost change if true concurrency were provided? Wouldn't thunk evaluation involve mutual exclusion? Dean Herington
I'm curious about the implementation of Concurrent Haskell in GHC and Hugs.
Hugs' implementation of concurrency is non-preemptive wherease GHC's implementation is preemptive (or "almost preemptive") as described by Simon.
Does access to values possibly shared among threads cost the same in Concurrent Haskell as in regular Haskell? I'm guessing the answer is "yes", because Concurrent Haskell is provided by default in GHC.
The answer is yes for Hugs.
If the costs are the same, does that rely on there being no true concurrency in the current implementations?
Just to be sure we agree on terminology: some people like to distinguish between "parallelism" and "concurrency". Parallelism is a way of going faster but doesn't change your programming model. Implemented correctly, a parallel implementation yields the same results as a sequential implementation - it just runs faster. (This is ignoring the effects of interaction with the outside world, of course - since that can also affect determinism.) Parallel Haskell adds "par" and friends (operations which have no effect on the semantics of your program). Concurrency changes your programming model. A concurrent program is allowed to give different results and interesting interactions (including race conditions) between threads. A concurrent program may run on a single processor. Concurrent Haskell adds forkIO, killThread, MVars, etc (operations which affect not just the semantics of your program but also the way the semantics are defined). You might want to use different words for those concepts but I hope the distinction is clear. (Note that the two concepts are rarely/never separated in imperative languages. Arguably, Esterel is an exception.) Using this terminology, I think what you're asking about is "parallelism" and not "concurrency". -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
By "true concurrency" I meant "simultaneous execution of multiple threads by multiple processors". This involves both concepts you define: "concurrency" (to have multiple threads) and "parallelism" (to have them execute possibly simultaneously when multiple processors are available).
From Simon Marlow's reply, I gather that the current implementations of Concurrent Haskell provide "concurrency" but not "parallelism", and that provision of parallelism is not likely in the near term.
I've asked these questions in order to convince myself that multiple threads can (and will) cooperate in lazily evaluating a value they share, without need for any special programming. In particular, I plan to have multiple threads share values whose computations involve uses of `unsafePerformIO` (the safety of which my application's usage pattern guarantees). Thanks to you and others for your helpful replies. Dean On 18 Mar 2002, Alastair David Reid wrote:
I'm curious about the implementation of Concurrent Haskell in GHC and Hugs.
Hugs' implementation of concurrency is non-preemptive wherease GHC's implementation is preemptive (or "almost preemptive") as described by Simon.
Does access to values possibly shared among threads cost the same in Concurrent Haskell as in regular Haskell? I'm guessing the answer is "yes", because Concurrent Haskell is provided by default in GHC.
The answer is yes for Hugs.
If the costs are the same, does that rely on there being no true concurrency in the current implementations?
Just to be sure we agree on terminology: some people like to distinguish between "parallelism" and "concurrency".
Parallelism is a way of going faster but doesn't change your programming model. Implemented correctly, a parallel implementation yields the same results as a sequential implementation - it just runs faster. (This is ignoring the effects of interaction with the outside world, of course - since that can also affect determinism.) Parallel Haskell adds "par" and friends (operations which have no effect on the semantics of your program).
Concurrency changes your programming model. A concurrent program is allowed to give different results and interesting interactions (including race conditions) between threads. A concurrent program may run on a single processor. Concurrent Haskell adds forkIO, killThread, MVars, etc (operations which affect not just the semantics of your program but also the way the semantics are defined).
You might want to use different words for those concepts but I hope the distinction is clear. (Note that the two concepts are rarely/never separated in imperative languages. Arguably, Esterel is an exception.)
Using this terminology, I think what you're asking about is "parallelism" and not "concurrency".
Dean Herington <heringto@cs.unc.edu> writes:
From Simon Marlow's reply, I gather that the current implementations of Concurrent Haskell provide "concurrency" but not "parallelism", and that provision of parallelism is not likely in the near term.
Uh, GPH exists, doesn't it? So you can get "parallelism" if you're after performance. The only implementation appears to be based on PVM, so I expect some overhead on SMPs, although I haven't gotten around to actually try it yet. I don't know if or how you can mix the two paradigms. There's also an implementation using threads for asynchronous calls to Win32 libraries, if I understand things correctly. A full thread-based parallel implementation might (or might not) be a logical next step. -kzm -- If I haven't seen further, it is by standing in the footprints of giants
Dean, Alastair Reid wrote:
Just to be sure we agree on terminology: some people like to distinguish between "parallelism" and "concurrency".
Parallelism is a way of going faster but doesn't change your programming model. Implemented correctly, a parallel implementation yields the same results as a sequential implementation - it just runs faster. (This is ignoring the effects of interaction with the outside world, of course - since that can also affect determinism.) Parallel Haskell adds "par" and friends (operations which have no effect on the semantics of your program).
Concurrency changes your programming model. A concurrent program is allowed to give different results and interesting interactions (including race conditions) between threads. A concurrent program may run on a single processor. Concurrent Haskell adds forkIO, killThread, MVars, etc (operations which affect not just the semantics of your program but also the way the semantics are defined).
We distinguish between parallel, concurrent and distributed depending on the number of processors and whether threads are *stateful*, i.e. access stateful objects like Mvars or Files, or *stateless*. That is: Sequential, e.g. Haskell 98: 1 PE, 1 Stateful thread, 0 stateless threads Concurrent, e.g. Concurrent Haskell: 1 PE, N Stateful thread, 0 stateless threads Parallel, e.g. GpH: N PEs, 1 Stateful thread, N stateless threads Distributed, e.g. GdH: N PEs, N Stateful thread, N stateless threads In fact these languages form an inclusion hierarchy, e.g. GdH is a superset of both GpH and Concurrent Haskell: GdH / \ GpH Conc. Haskell \ / Haskell 98 Dean Herington wrote:
I've asked these questions in order to convince myself that multiple threads can (and will) cooperate in lazily evaluating a value they share, without need for any special programming. In particular, I plan to have multiple threads share values whose computations involve uses of `unsafePerformIO` (the safety of which my application's usage pattern guarantees).
The key issue is whether the 'values' are stateful (e.g. Mvars or Files) or stateless (e.g. a shared Haskell variable). Sharing stateless objects between parallel, concurrent, or distributed threads preserves sequential semantics, but sharing stateful objects can introduce non-determinism, unless you have additional properties. Phil -------------------------------------------------- Phil Trinder Department of Computing and Electrical Engineering Heriot Watt University Riccarton Edinburgh, EH14 4AS E-mail: trinder@cee.hw.ac.uk Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: http://www.cee.hw.ac.uk/~trinder
participants (4)
-
Alastair David Reid -
Dean Herington -
ketil＠ii.uib.no -
Phil Trinder