[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-users] Re: An alternative thread system?

From: Aleksej Saushev
Subject: [Chicken-users] Re: An alternative thread system?
Date: Mon, 11 Aug 2008 10:25:22 +0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix)

Ivan Raikov <address@hidden> writes:

>   I agree that message-passing in general can be made as
> incomprehensible and non-deterministic as threads. So one should
> carefully choose their message-passing abstraction. But for example
> Unix pipes guarantee that messages between two processes will be
> received in the same order they are sent, which is already a much
> stronger guarantee than what you get with threads and their
> do-it-yourself approach to synchronization. 
>   So even an abstraction as simple as pipes already hides a lot of
> complexity that shared-memory designs have to deal with explicitly. If
> you look at Erlang, which is a language designed to be concurrent at
> the core, its principal concurrency abstraction is message-passing,
> not shared memory. Not to mention that most research efforts into
> concurrent languages ended up devising process calculi with much, much
> stronger determinism than shared-memory concurrency. 
>    The moral of the story is that systems whose behavior is governed
> by an explicit, unchanging set of states and transitions is much
> easier to reason and think about, than are shared-memory systems whose
> behavior may be determined by instruction timing-- something that the
> programmer has no control over, and cannot monitor other than with
> very sophisticated debugging tools. Message passing can provide this
> explicit determinism, while shared-memory threads might be able to do
> so only at the expense of very complicated (and slow) locking
> semantics.

The point is, threads are not complex to debug, what is complex
is shared access to memory, which you can easily avoid.
Pipes are not that simple actually, to pass some complex structure
through pipe, you need to pack it to some structure on one end, 
parse and unpack on the other end (note all those XML/YAML encodings),
while with _some_ shared memory you could just pass the reference.

Again, the problem isn't in threads or shared memory, it is in
abstractions used. It is like modular programming vs. the
ancient non-modular one (with lots of shared variables &c).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]