Re: Multithreading: Batch vs. interactive.

Hi, Scott:

Please see my embedded remarks below ...

> Scott Klement wrote:

IMHO, the biggest problem with multi-threaded applications is that there's no really good way to debug them or perform QA on them.

Not strictly true -- see the following articles:

http://brinch-hansen.net/papers/1973c.pdf
and
http://brinch-hansen.net/papers/1978b.pdf

for examples of systematic methods of testing multiprocessing programs developed in the early 1970s.

Walden suggests that programmers don't "do it right", and Mark says that the environment doesn't "hide the complexity". I agree with both of these statements, however, for me the really important problem is, it doesn't tell you when you're doing something that isn't threadsafe or might create a deadlock.

There's really no good way for the compiler to detect those things.

Thiat may be true for ILE RPG IV or the ILE C compiler. But programming languages and compilers have been designed to address these problems. See:

http://brinch-hansen.net/papers/1972a.pdf
and
http://brinch-hansen.net/papers/1975a.pdf

for examples of programming languages and compilers that were designed to address these problems at compile-time.

There's really no good way for the programmer to test their apps to see that they are doing everything in a threadsafe manner, or that they won't create deadlocks. When something does fail during testing (or production) there's really no way to tell what the problem is, and when you try to debug it further (by running in a debugging tool, running a trace on what's happening, etc) it changes the timing and therefore doesn't reproduce the problem (at least, not the same way)

It is not so much that "there is no way to tell what the problem is," but rather, it is just far more difficult to isolate the problem(s) and it is much harder to reproduce these kinds of problems.

So the only way to find/fix bugs is when the programmer really groks threads, and can imagine the problems of the program when desk-checking the code. Anyone with programming experience knows how hard that is to do!

Certainly, it is not a bad idea for programmers to "grok" threads, and "desk checking" never hurts either. But, IMHO, the real problem is, there are far too many "prima donna" programmers who prefer to use unsafe languages like C, where it is all too easy to create buffer overruns, and just overlay some memory by the incorrect use of pointers, etc. -- and then, in the Unix tradition, they just "graft on" threads capability by using the pthreads library. Similarly, Java also followed the c-threads or pthreads model. See below for an article that describes the problems with this approach:

http://brinch-hansen.net/papers/1999b.pdf

So, the problem is, you cannot simply allow use of thread primitives (such as mutexes, semaphores, etc.) from within an existing higher-level language (including RPG IV), and expect programmers to be able to write "thread-safe" programs. The paradigm has to be designed into the language, and the compiler must be able to check for (or verify) proper ("safe") use of such features.

So I really hate multithreaded programming. Not because the OS doesn't hide the complexity, but because it doesn't yell at me when I do something wrong.

It is not solely the responsibility of the operating system, but a good higher-level language compiler, and its runtime environment, should, and really, must support an appropriate, type-safe paradigm for using these powerful facilities.

Mark S. Waterbury