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

[Aleksej Saushev]

Elf <address@hidden> writes:

> On Mon, 11 Aug 2008, Aleksej Saushev wrote:
>
>> 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).
>
> Disagreed absolutely.  Threads can be incredibly complex to debug, even
> ignoring shared memory issues.  Threads can get stuck in dependency loops
> very quickly while waiting on I/O, even from possibly different
> sources.

How does it differ from communicating processes in this respect?

> Threads can get interrupted in all kinds of unpleasant
> ways without being detectable as such.

Irrelevant again, so are processes.

> If you're the sort of person who uses a debugger (I'm not), to
> the best of my knowledge no debuggers handle multithreaded
> software particularly gracefully.

This is your personal taste and your personal problems, isn't it?

>  You don't need all the XML/YAML/Whatever-This-Months-Buzzword-Is.
> It's pretty trivial to define a small, customised format for
> messages in your application.  It's also easy to add sanity
> checking to messages, so the receiver can detect if the sender
> is in an inconsistent state (or if the message was, at very
> least) and try to correct for it.  It's easy to add new
> message capability to the system with a new process handling
> it, because its a lot more loosely coupled.  It's easier
> to keep data formats small.

Noone argued against message-passing interface above. Really.

> The potential for race conditions is greatly diminished if the
> implementor was not a total idiot about security.  The flow of
> the program is deterministic and verifiable.  This last condition
> is not possible, to the best of my knowledge, in threading
> systems, without having the scheduler be so restrictive and
> have so much information about everything beforehand that it
> essentially runs as a single-threaded program.

How does that differ for multiple processes?

It seems, that you've lost the point of the message you reply to:
given some restrictions to communication between threads, there's
almost no difference between processes and threads, semantically,
and at the same time threads are more flexible and more effective.

No offence, it seems to me, that you've lost the flow of the talk,
catch up, please. Maybe it is my fault either, since I could try
to express more clear.


-- 
CE3OH...