question about concurrency implementation
Phil Trinder
trinder@cee.hw.ac.uk
Thu, 21 Mar 2002 09:19:44 +0000 (GMT Standard Time)
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