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.
However, even in the single threaded case, code can appear to work for a long time (potentially years) and eventually fail because it was not coded correctly. While the code may not get bored or distracted, changes in its environment can make it fail intermittently. This is, of course independent of concurrency considerations.
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.
Unless I misunderstand, though the separate threads still share the same file system, sockets, environment, etc. many of which are subject to cause interactions if the programmer is not careful. If I'm understanding the issue correctly, iThreads make memory non-shared by default. While the threads are more isolated this way, they are not completely independent.
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.
I obviously missed something in my explanation. I was not seeing the conductor or teacher as portions of the threaded code, the programmer is in the position of the 'teacher' or 'conductor' in these analogies.
Let me try another way.
In most single threaded programs, the programmer can lay out a sequence of steps with appropriate control logic. You can pretty much see how the code will run from beginning to end. (More complicated problems make this harder to see, but bear with me for a moment.)
In a multi-threaded program, on the other hand, the programmer builds smaller, independent sequences of steps that run under their own control. Any place that these threads need to interact is not under the direct control of the programmer. So the programmer is kind of one step removed from the code. This makes understanding the interactions and timing (for lack of a better word) more important in this style than in single threaded code.
It's been my experience that many people find this harder. Or they code assuming that things will behave the way they want (like it did in the single threaded model). These people are often stumped when their code doesn't work.
Obviously, the fewer the interactions between the threads (not accessing shared resources and such), the less the coordination issues will affect us. If there's no interaction between the threads, then I wonder why they are in the same program.
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.
These are the lessons I also learned from multi-threading work, even without iThreads from the mid 90s. But, these approaches do not always come naturally when someone tries threads for the first time.
I guess that is what I've been trying to say (but have only done so badly). Multi-threading and single threading benefit from somewhat different viewpoints and tool sets. Someone doing threads for the first time should be aware that the different tools and viewpoints may be needed.
In reply to Re^5: Multithreading, how to?
by gwadej
in thread Multithreading, how to?
by iSina
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |