chicken-users
[Top][All Lists]
Advanced

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

Re: [Chicken-users] critical-section not in Chicken 3?


From: Ivan Raikov
Subject: Re: [Chicken-users] critical-section not in Chicken 3?
Date: Wed, 06 Feb 2008 22:06:56 +0900
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

  That's a really good point, and my aversion to threads was one of
the reasons why I created the mpi egg. MPI forks processes that are
completely separate from each other, and yet it provides enough
synchronization and communication primitives for fairly complex
concurrent applications. And my experience shows that the
communication overhead of MPI is negligible for most situations where
threads are used -- I will be happy to be proven wrong about that, if
anybody can provide realistic counterexamples.

  And to add my own rant about threads: I am amazed by the number of
programmers who fully believe that they understand how to design and
implement threaded code and yet cannot produce solid designs. I have
yet to meet the engineer who can produce a multithreaded software
system that can be entrusted with a critical role. I am willing to
believe that such persons exists; however, I have only encountered a
large number of programmers who simply fail at multithreaded design,
and even worse, in some cases they do not understand that they have
failed.

   If anybody thinks that multithreaded designs are simpler or more
efficient, please consider this: most general-purpose thread
schedulers naturally use time as an independent variable in their
scheduling algorithm, and therefore if you use threads, then you have
introduced time as an input of your program. So the slightest
variability in how time is measured (such as a different CPU clock,
interrupts, etc.) will alter how your threads interact, and your
program will very likely perform differently in situations with
different timing characteristics of the runtime environment. Running
your program in gdb throws off thread synchronization
completely. Merely adding debug prints may alter the timing
behavior. Changing compiler optimization options may alter the timing
behavior. Etcetera, etcetera, etcetera. Many synchronization problems
with multithreaded code are next to impossible to catch with routine
testing, because the failure rate can be pretty low on the developer's
machine.  You will spend more time doing time-consuming full-coverage
testing on a range of systems, than if you had designed a
single-threaded even-driven system to begin with.

  It is quite frustrating that so many programmers choose to
multithread their software when it is not necessary, and introduce all
kinds of complications for themselves and their users. Just say no to
threads.


   -Ivan


"felix winkelmann" <address@hidden> writes:

> <rant>
> Threads are a mess. Threads break encapsulation. Even creating a
> critical section might influence concurrently running threads with
> tight timing constraints. Multithreading is in nearly all cases the modern
> equivalent to spaghetti code. There are sometimes situations where
> spawned threads are completely self-contained (like in a web-server),
> but in most cases threads should be avoided.
>
> IMHO.
> </rant>




reply via email to

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