[Top][All Lists]

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

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

From: Elf
Subject: Re: [Chicken-users] Re: An alternative thread system?
Date: Mon, 11 Aug 2008 12:43:19 -0700 (PDT)

On Mon, 11 Aug 2008, Aleksej Saushev wrote:

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

How does it differ from communicating processes in this respect?

Single threaded processes cant get stuck in mutual dependency loops.  The OS
can reschedule them.  Single threaded processes can be written in such a way
to guarantee that whatever is being waiting for is the next thing that needs to be run. Threads generally cannot do either of these. There is no
general purpose method of breaking deadlocks in pure thread models that does
not violate consistency of one or more of the deadlockers.

This is the biggest difference between threads and processes, from a user viewpoint. Processes only have to know about themselves, and how they operate, to maintain consistency/correctness. The OS process scheduler can
handle everything else very simply without causing problems.  Conversely,
threads have to know about every other thread in the program at all points
in time in order to guarantee correctness. The only way around this is to write a scheduler that controls them all, where they only have to block for
input.  Sound familiar?  If not, take a peek at Felix's implementation. :)

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

Irrelevant again, so are processes.

No, they cant. There isnt a per-thread signal handler (at least not at the moment) in chicken, there is one signal handler that accepts everything. Which signal may be aimed at whom is for the signal sender to know and the
scheduler to guess.  (Do you feel lucky, punk? :) )
Conversely, processes each have their own signal handler and any well-designed
program installs the relevant cleanup handlers.

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?

No. I don't use debuggers. The #1 problem that I hear from people who DO have to use them constantly is that its well-nigh impossible to debug any
non-trivial threaded program.

 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.

My point was only that its much simpler to do message-passing (4 calls needed
at system level) than to do inter-thread communication (some ungodly number,
depending on how things like mutexes are handled).

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?

If multiple processes are spawned by the same program, they can be timed
to not conflict with each other.  If multiple threads are spawned by the
same program, there's no assurance that the creating thread won't lose its
timeslice before it should (and in fact almost always will, if you do sleep
calls), nor is there any guarantee as to which thread will be started.

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.

I was responding to it, merely disagreeing with it.  threads are neither
more flexible, more effective, safer, nor easier to work with. Semantically, processes and threads differ because of the controller that
exists in one model (scheduler) that does not exist in the other.

terminating your threads since you bought them last week, boyyyyyy

reply via email to

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