Re: Multithreading: Batch vs. interactive.

Many typical applications programmers are ill-equipped to deal with the complexities of multi-threading. (Just consider how many developers are still programming in RPG/400 versus RPG IV, let alone using any of the "new" features of ILE, such as *SRVPGMs, etc.)

I am not just picking on RPG programmers. Even developers with years of C experience often have great difficulty developing "thread-safe" multi-threaded applications that do not end up with "race conditions" or other "deadly embraces" etc., or that simply do not live up to the expectations of multi-threading (such as improved performance, etc.)

In my opinion, the problem is somewhat akin to what happened when computers first appeared.

At first, you had to program computers directly in binary machine language (1st generation). Then, assembler languages were invented, that made the task a little easier for humans to comprehend (2nd Generation languages). Then. the first HLL compilers began to appear by the mid-to-late 1950s (such as COBOL, FORTRAN, etc.) -- so-called 3rd Generation languages.

By way of comparison, I think the "state of the art" (such as it is) today with "multi-threading" is still stuck at the 1GL or 2GL level; the paradigms and programming models, etc., for writing multi-threaded applications are rather primitive, and they do not hide any of the complexities from the developer. So, is it any wonder humans have difficulty writing correct multi-threaded applications that are "thread-safe" and perform well?

IBM more or less invented "threads" (light-weight multitasking) back in the late 1960s when they developed CICS to allow multiple terminals to run different applications on behalf of multiple users, simultaneously, all within a single MVT or DOS batch job. The brilliant thing about CICS, that is largely responsible for why CICS survives even today, is that the CICS API (from the application developer's point of view) made it fairly easy to write on-line applications that worked well, while hiding much of the inherent complexity.

Until someone figures out how to do something like this for modern multi-threaded applications written in modern HLLs, I think it will continue to be difficult to write "correct" multi-threaded and "thread-save" applications.

Mark S. Waterbury