[Haskell-cafe] Can you do everything without shared-memory
concurrency?
Jason Dusek
jason.dusek at gmail.com
Tue Sep 9 20:21:00 EDT 2008
Bruce Eckel <bruceteckel at gmail.com> wrote:
> ...shared-memory concurrency is impossible for programmers to
> get right...
Explicit locking is impractical to get right. Transactional
interfaces take much of the pain out of that -- even web
monkeys can get shared memory right with SQL!
When two instances of a web app interact with the database,
they are sharing the database's memory. So you have locking,
mutual corruption and all that jazz -- yet you seem to be
message passing! More generally, applications backed by
network services -- which are presented through a message
passing interface -- are shared memory applications much of
the time (though a bright service can tell when modifications
are unrelated and run them in parallel).
Message passing certainly makes it easier to write parallel
applications, but does it provide any help to manage shared
state? No. None whatsoever. If you have a bunch of programs
that never share state with one another, they are a single
application in name only.
Using locking as your default mode of IPC is harrowing, but
you can do anything with it. Using message passing is simpler
in most cases, but you'll have to implement locking yourself
once in awhile. Language level, transactional interfaces to
memory are going to cover all your bases, but are rare indeed
-- as far as I'm aware, only Haskell's STM offers one.
> ...the unnatural domain-cutting that happens in shared-memory
> concurrency always trips you up, especially when the scale
> increases.
This is true even with transactional interfaces. Message
passing is _like the network_ and makes you think about the
network -- so when it's time to get two servers and hook them
together, you are already ready for it already. Transactional
shared memory is not at all like the network. Why not? In a
transactional system, a transaction can not both be approved
and unwritten. On the network, though, these are separate
messages, going in different directions -- they can fail
independently.
--
_jsn
More information about the Haskell-Cafe
mailing list