From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ab2ba9c5d12b0f12 X-Google-Attributes: gid103376,public From: "Kevin J. Weise" Subject: Re: Concurrency in Gnat 3.05? Date: 1996/07/18 Message-ID: <4slgeq$hr4@michp1.redstone.army.mil> X-Deja-AN: 169537125 references: <4sjqte$3mu@masala.cc.uh.edu> content-type: text/plain; charset=us-ascii organization: Redstone Arsenal, Alabama mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 1.22 (Windows; I; 16bit) Date: 1996-07-18T00:00:00+00:00 List-Id: 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