question about concurrency implementation

[Dean Herington]

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".