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" <[EMAIL PROTECTED]> 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> _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
