Re: Multithreading: Batch vs. interactive.

["Mark S. Waterbury" <mark.s.waterbury@xxxxxxx>]

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