And that is exactly the kind of, somebody-I-knew-tried-it-once-and-told-me-it-was-really-hard, uninformed mis-information and kneejerk FUD that pervades and predominates whenever any of the terms:

'asynchronous programming', 'multi-processing', 'multi-tasking', 'distributed processing', and 'multi-threading'

arise in discussion.

Brain surgery is difficult and fraught with dangers, but sometimes it is the best--and sometimes the only--option.

I do like the imagery though. Despite the fact that a kindergarten teacher may be able to get a group of 5 year olds to work together to accomplish some relatively impressive things, that does not mean that any random adult can do the same.

The guy who mentored me in multi-threading suggested an analogy that I've always found useful. Writing multi-threaded code is to writing single-threaded code as playing a musical instrument is to conducting an orchestra. A single musician can be a little sloppier and ad-lib quite a bit without ruining the result. That doesn't work with an orchestra. (You could argue it does work with a good Jazz band.) This is not to say that individuals are sloppier, but a single person does not have the coordination issues that an orchestra does. (Disclaimer: I am not a musician and don't even play one on the Net.)

The point is not that you should never use threads, but that organization and coordination become more important.

The suggestion that you try multi-threading in a smaller experiment before applying it to a big system does not seem to be FUD to me. I would give the same advice to someone trying out a new programming language, methodology, framework, or any other piece of technology.

I suspect that much of the FUD about threaded code out there is spread by people who jumped in with both feet, rather than doing a test program. At least, that has been my experience with some who are fanatically against any form of threading.

G. Wade

Again, I don't disagree with you with regard to threading in general.

I do like the imagery though. Despite the fact that a kindergarten teacher may be able to get a group of 5 year olds to work together to accomplish some relatively impressive things, that does not mean that any random adult can do the same.

The problem with this analogy, as with the musicians, is that programs do not have minds of their own; and so are not subject to variable skill levels, PMS, hangovers, distraction by the musician in front's flimsy or tight clothing, or any of the other factors that can distract and disrupt human beings.

With code, once the right steps are codified and verified, the computer will happily perform those steps over and over precisely without getting bored, tired or distracted. The same does not hold true for human beings.

Once a piece of code, say a subroutine, is tested to work correctly as a single threaded, standalone environment, it will continue to work correctly when you run multiple copies of it concurrently. Provided that there are no unintentional interactions between the copies.

And it is in exactly that last area where iThreads are pretty much unique relative to most other forms of threading. The core concept that distinguishes them is that you have to explicitely arrange for anything to be shared. If you share nothing, there can be--barring errors in the core implementation; which do crop up occasionally in this field just as they do in every other field--no accidental interactions.

That single fact alone makes iThreads different from most other forms of threading.

The second major flaw in the multiple persons analogy is that with few exceptions, the success of human group activieties is dependant upon the management, coordination and timing of the interactions between the individuals. Hence the 'teacher' & 'conductor' roles in those analogies.

Whilst there are tasks that can benefit from multitasking that require such a coordinating and synchronising role, there are also whole classes of applications that do not. Collectively termed data-parallel, for which applying iThreads multi-threading to well-tested, single-threaded code requires minimal changes and (almost) no knowledge of the deep voodoo that is required to use other forms of threading.

I wrote my first threaded code--under OS/2--circa the late 80's under OS/2, and have made most of the mistakes--often multiple times! I've been involved in both successful and unsuccessful projects that used extensive kernel threading, but using iThreads has taught me things that I never seen described anywhere in the literature.

The most important of those lessons is that the easiest way to avoid the well-known problems of deadlocking, priority inversion et al. is to simply avoid using the mechanisms that lead to them. It sounds too simple to be true, but in the vast majority of the use cases I have explored, I've found relatively simple and reliable solutions that use iThreads, Queues, minimal shared data and minimal locking.

And in the few non-perl threaded applications I've been involved in since getting familiar with iThreads, I've found that lesson transfers quite well to other languages like C(++), Clean and more.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

But don't try it witout 10+ years of education and training, at least not on your children.
It is always better to have seen your target for yourself, rather than depend upon someone else's description.