Re: Concurrency in Gnat 3.05?

["Kevin J. Weise" <kweise@c3i-ccmail.sed.redstone.army.mil>]

cosc19z5@Bayou.UH.EDU (Spasmo) wrote (with deletions):
>Hey all.
>
>Is Gnat 3.05 (for DOS) truly concurrent when executing tasks?  I'm
>asking because I've written some tasking code (finally got it
>to link) and when I ran the code, the tasks didn't run
>concurrently at all.  I'm running in a Win95 DOS box.  One task
>runs to completion before the other task starts up.  I've also
>tried some sample code including Feldman's Twotasks program
>and they exhibit the same behavior.  Is there a way to get
>tasks to run concurrently, or would I have to look for a
>GNAT that's native to something like WinNT/95 that can
>handle multi-tasking?
>
>Thanks in advance.
>

There are several factors that come into play here.  First of all, on a uniprocessor 
system, "true concurrency" is impossible as only one task can have the CPU at any 
one instant in time.  If by "true concurrency" you mean multiple tasks being in some 
state of execution at any instant (i.e., logical concurrency), regardless of which 
one has the CPU, then we get into context switching policy.  Multiple processors 
system have a whole slew of other factors involving dispatching on the various CPUs 
and synchronization, but I don't think you need to worry about that now.

Task priority as a context switching policy is conceptually simple; higher priority 
tasks get the CPU before lower priority tasks.  However, changing priorities will 
not appreciably alter the behavior you describe (other than perhaps to change the 
order in which tasks run to completion).  Priority by itself is insufficient as a 
context switching policy, however, as other factors can lead to the dreaded 
"priority-inversion" syndrome, where higher priority tasks can be blocked by 
lower-priority tasks.  

Another context switching policy where we start getting into logical concurrency is 
the criteria provided by the underlying tasking kernel for taking the CPU away from 
one task and giving to a different one.  There are two basic "flavors" (I use this 
term loosely, as vendors who implement these kernels will tell you there are a lot 
of variations & combinations):  execute until blocked, and context switch on 
external events.  Timeslicing is a form of context switching on external event, and 
is what modern multiuser multiprogramming OS's (e.g. UNIX) do well; each process 
gets the CPU for a certain amount of time (until the computer clock interrupts), at 
which point the OS takes the CPU back and re-evaluates which process should get the 
CPU next.  It's possible, based on demand, priority, & other factors, that the 
process that was just executing will get the CPU back, but other processes get a 
shot at getting the CPU, too.  It is vital that this operation be invisible to the 
affected processes. (BTW, the DEC-VAX/Ada tasking kernel provided a timeslicing 
policy so that within a VMS process Ada tasks could have their execution 
interleaved, if users wanted it.)  This is one example of outside events affecting 
program behavior.  Obviously, other outside events (e.g. I/O interrupts) can 
similarly affect program behavior, if the tasking kernel supports it (esp. when 
combined with task priority).  Support by the run-time kernel for this "flavor" is 
vital for preemptive multitasking.

The other remaining "flavor" (execute until blocked) means that whatever task gets 
the CPU keeps it until it can execute no further (i.e, becomes "blocked").  Typical 
blocking factors include (but are not restricted to) I/O operations (esp. waiting 
for input) and synchronization operations (i.e., delay, rendezvous).  This was the 
usual policy in the early Ada83 run-time kernels; I believe most support some degree 
of preemptive multitasking now.

Overall, I guess the question is, does GNAT run-time system support preemptive 
multi-tasking, and to what degree?  This is target-dependent.  But I know this much: 
 GNAT's run-time system uses POSIX threads (pthreads).  If your underlying OS 
supports pthreads directly, then you should be in fat city.  If it does not, then 
someone needs to provide that support at some level.  Early MSDOS ports of GNAT (as 
well as many UNIX ports) stubbed out pthreads due to lack of support.  DJGPP does 
provide some level of pthreads support, but I don't know how much (certainly enough 
to allow a run-time kernel to be linked into your executable that issues calls upon 
DJGPP pthreads).  I think you need to go to the Win95 implementation of GNAT.
>
>--
>Spasmo
>"Here's a present just for you
>When you open it, you'll be through"
>	"Letter Bomb" by the Circle Jerks
>
------------------------------------------------------------------------
Kevin J. Weise                   email:  kweise@sed.redstone.army.mil
COLSA Corporation                voice:  (205) 842-9680
Huntsville, AL  35806

.. standard disclaimers apply