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

[Aleksej Saushev]

Elf <address@hidden> writes:

> On Mon, 11 Aug 2008, Aleksej Saushev wrote:
>
> <snip>
>>>> 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?
>
> Single threaded processes cant get stuck in mutual dependency loops.

Oh, really? Create socket, start two processes, and wait on input on both sides.
Of course, the OS will save you, it magically knows how to reschedule them.

> 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.

Have you ever used operating system with no MMU? Processes and
threads are the same in relevant parts here.  There's no
difference in behaviour of multiple processes and multiple
threads, in both cases you see deadlocks, races and contention.
All relevant mechanisms are just the same.

> 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.

That's not true. If processes operate cooperatively, they should
know about each other. E.g. SMTP and NNTP server and client, ssh
server and client, etc. If some SMTP goes wild, the other has to
drop connection after timeout. Database replication daemons are
even more dependent on mutual communication protocol.

>>> 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

The original topic has nothing with signal handlers,
OS scheduler can just stop process and swap it off for a while,
you have rather limited control over it, unless you're doing
real-time job.

> (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? :) )

That's the limitation of particular virtual machine, not the
thread at all. This has nothing to do with original topic.

> Conversely, processes each have their own signal handler and
> any well-designed program installs the relevant cleanup handlers.

This is the limitation of particular process model, which has
nothing to do with original topic.

>>> 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.

Again, this is irrelevant to differences between communicating
threads and processes. Actively communicating processes are as
hard to debug.

>>>  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).

You can pass messages with _no_ context switches at all.
Faster than processes.

The overhead of interthread communication is implementation
dependent, and it is still faster than IPC due to no user-to-kernel,
kernel-to-user copy. With IPC you still have same locks, only in
kernel space.

You can use those very pipes to communicate between threads.

>>> 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.

Processes can't be timed, if some I/O interrupt happens,
scheduler may decide to stop the process. When it will be
resumed, you've lost time. There may be one common scheduler
for both, processes and threads. So, all may be equal before
the Scheduler.

>> 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.

You failed to prove it.

And on the other hand we have enough empiric material, where
converting to threads raised overall performance.

> Semantically, processes and threads differ because of the
> controller that exists in one model (scheduler) that does not
> exist in the other.

What? Where did you read that? Please, read man page about
pthread_setschedparam/pthread_setschedparam, or find the
standard referenced there, ISO/IEC 9945-1:1996, and read it
there.


-- 
CE3OH...