Re: Concurrency in Gnat 3.05?

Re: Concurrency in Gnat 3.05?

[Kevin J. Weise]

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

Re: Concurrency in Gnat 3.05?

[Robert Dunn]

In article <4sjqte$3mu@masala.cc.uh.edu>,
 on 17 Jul 1996 22:53:34 GMT,
 Spasmo <cosc19z5@Bayou.UH.EDU> writes:
>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?
>
>

Ok, here is how you answer that question.  Go get yourself both a
phillips and a t-15 screwdriver.  Now, remove the cover from your
Win95/DOS7.0 Box.  Count the number of processors.  If you counted
one, you are absolutely correct.  Now, ask yourself, how many
operations can run on one processor at a time.  If you answered one
again, you now have two points.  ;>

Now, for the big question?  Can one processor run two (or more) tasks
concurrently?  If you answered no, you have just won the grand prize.

The question that now remains is, How do you make a single processor
seem as if it is doing more than one thing at a time.  Did you say
time slicing?  Well, that is correct.  And what is time slicing
synonomyous (ok so I can't spell) with?  OVERHEAD!!!

The logical conclusion therefore is to save the overhead by allowing
a task to run until a natural break (eg completion, accept, call, etc).

Yes, it would be nice to have true multi-tasking.

Sorry if this sounds harsh, it is designed to entertain.  Of course,
I have yet to meet a programmer who didn't have a unique sence of humor.

Re: Concurrency in Gnat 3.05?

[Jerry van Dijk]

Spasmo (cosc19z5@Bayou.UH.EDU) wrote:

: Is Gnat 3.05 (for DOS) truly concurrent when executing tasks?

The theoretical answer is: no, of course not, if you are running
on a single processor.

But what you probably wanted to ask is: does GNAT/DOS do multi-tasking ?
The answer, yes. But not pre-emptive tasking, what seems to be what you
expected, but cooperative tasking. 

>  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.

I'm not using Win95 but when I was playing around with the tasking
like that I sprinkeled it with small delay statements to ask for a task
switch...

: or would I have to look for a
: GNAT that's native to something like WinNT/95 that can
: handle multi-tasking?

You might, but I am not sure if the Win/NT version will map to native threads
under Win95. 

-- 
-----------------------------------------------------------------------
--  Jerry van Dijk       --   e-mail: jerry@jvdsys.nextjk.stuyts.nl  --
--  Banking Consultant   --              Member Team-Ada             -- 
--  Ordina Finance BV    --    Located at Haarlem, The Netherlands   --

Re: Concurrency in Gnat 3.05?

[Samuel Tardieu]

>>>>> "Spasmo" == Spasmo  <cosc19z5@Bayou.UH.EDU> writes:

Spasmo> Is there any place where I can find some detailed GNAT
Spasmo> specific docs? I know my questions are simple newbie ones that
Spasmo> could be answered given some detailed GNAT docs, however all
Spasmo> the docs I have seem to be about installation, or DJGPP, so I
Spasmo> end up wasting bandwidth asking newbie questions because I
Spasmo> can't seem to find the answers anywhere.

In the GNAT distribution, there should be a file called
gnatinfo.txt. In this file, you should find everything you want and
even much more :-)

Spasmo> Is Gnat 3.05 (for DOS) truly concurrent when executing tasks?

AFAIK it's not, but there is nothing in the RM that requires it !

Spasmo> I'm asking because I've written some tasking code (finally got
Spasmo> it to link) and when I ran the code, the tasks didn't run
Spasmo> concurrently at all.

Have you tried to use priorities ?

Spasmo> I'm running in a Win95 DOS box.  One task runs to completion
Spasmo> before the other task starts up.

That's common when you have a monoprocessor. If you need one of your
task to be more "reactive", you may increase its priority (assuming it
won't hog your whole CPU power).

Spasmo> I've also tried some sample code including Feldman's Twotasks
Spasmo> program and they exhibit the same behavior.  Is there a way to
Spasmo> get tasks to run concurrently, or would I have to look for a
Spasmo> GNAT that's native to something like WinNT/95 that can handle
Spasmo> multi-tasking?

Once again, multitasking doesn't imply time-sharing between
same-priority tasks. You may have true multitasking with no
time-sharing.

Anyway, as long as you have preemptive tasking, you may achieve what
you are trying to do by adding a task running at an higher priority
and waking up every <n> microseconds to give one of your two task a
priority highest than the second one. 

Example: let's assume you have two tasks T1 and T2, running at the
same priority level L. You want to do time-sharing between these two
tasks. You add a task S (scheduler) running at priority L+2, which
"delay"s for <n> microseconds then sets the priority of T1 to L+1 and
the one of T2 to L (and vice-versa each two times), and then delays
again, ... This way, your two tasks T1 and T2 run concurrently.

  Sam
-- 
"La cervelle des petits enfants, ca doit avoir comme un petit gout de noisette"
                                                       Charles Baudelaire

Re: Concurrency in Gnat 3.05?

[Robert Dewar]

Spasmo said

Ok, before I get on with my main question, I've got another.  Is
there any place where I can find some detailed GNAT specific docs?
I know my questions are simple newbie ones that could be answered
given some detailed GNAT docs, however all the docs I have seem
to be about installation, or DJGPP, so I end up wasting bandwidth
asking newbie questions because I can't seem to find the answers
anywhere.  Well on to my next newbie question :)

  The current documentation is gnatinfo.txt, which I assume you have read
  since it is included in all GNAT releases. If not, you have completely
  missed the primary available documentation!

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?

  Of course it is not truly concurrent, there is no such thing as true
  concurrency on a monoprocessor! The processor can only do one thing
  at a time! What you are asking is whether it time slices among equal
  priority tasks, and the answer is that it does not, and that Ada 95
  dispatching semantics does not permit time slicing in its default:
  The following is from RM annex D.

4   Task dispatching is the process by which one ready task is selected for
execution on a processor.  This selection is done at certain points during
the execution of a task called task dispatching points.  A task reaches a
task dispatching point whenever it becomes blocked, and whenever it becomes
ready.  In addition, the completion of an accept_statement (see 9.5.2), and
task termination are task dispatching points for the executing task.  Other
task dispatching points are defined throughout this Annex.

  Time slicing is available when GNAT runs over some operating systems where
  tasks are mapped to threads, and the threads provide time slicing (whether
  this conforms to annex D is an interesting question .. it certainly does
  not conform to the spirit of annex D, but you can argue that you are
  simulating the effect of a multi-processor.

  In any case, the bottom line is that tasks do NOT time slice on DOS, and
  any Ada program that depends on time slicing is not portable, and is
  depending on implementation specific alternative scheduling policies.

Re: Concurrency in Gnat 3.05?

[Robert Dewar]

Spasmo says

"Well others did manage to do it, so I had assumed that GNAT
was the same.  Still it's a shame not having tasks that
time slice, I mean it doesn't really seem all that big a
deal to have tasking when they don't appear to run
concurrently.  Entries into them and all are allright,
but still without time slicing..."


That's quite wrong. Serious use of tasking for real-time programs
generally prefers to completely avoid time slicing. That is why the
requirement in the real time annex of Ada is that time slicing must
NOT occur using the default scheduling policy (FIFO_Within_Priorities).

Generally time slicing can be made available on many operating systems,
but it is a bit tricky in DOS, because of limitations in the operating
system. It certainly would be possible, but since it is not required (in
fact it is only permitted as an option), it is not a high priority item.

If what you want is effective concurrency between multiple threads, there
are many ways to achieve this in correctly programmed Ada. An Ada program
that depends on time slicing is non-portable.

Re: Concurrency in Gnat 3.05?

[Robert Dewar]

Jon said

"The point is that time slicing behavior is system dependent.  For
example, GNAT on Solaris maps tasks to threads and they will behave as
you were expecting (switching context for IO, etc.)"

Yes, in fact the default behavior on Solaris clearly violates the Ada 95
standard in that time slicing does occur. We are investigating the use
of the real time priority levels in Solaris which should make it possible
to correct this incorrect behavior.

Re: Concurrency in Gnat 3.05?

[Spasmo]

Robert Dunn (red@satcom.whit.org) wrote:
: In article <4sjqte$3mu@masala.cc.uh.edu>,
:  on 17 Jul 1996 22:53:34 GMT,
:  Spasmo <cosc19z5@Bayou.UH.EDU> writes:
: >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?
: >
: >

: Ok, here is how you answer that question.  Go get yourself both a
: phillips and a t-15 screwdriver.  Now, remove the cover from your
: Win95/DOS7.0 Box.  Count the number of processors.  If you counted
: one, you are absolutely correct.  Now, ask yourself, how many
: operations can run on one processor at a time.  If you answered one
: again, you now have two points.  ;>

: Now, for the big question?  Can one processor run two (or more) tasks
: concurrently?  If you answered no, you have just won the grand prize.

: The question that now remains is, How do you make a single processor
: seem as if it is doing more than one thing at a time.  Did you say
: time slicing?  Well, that is correct.  And what is time slicing
: synonomyous (ok so I can't spell) with?  OVERHEAD!!!

Ok, Time slicing -- whatever :).  Still, with Linux I could easily
write C programs that used time slicing on my processor courtesy
of fork(), so I had assumed that GNAT also did something similar
with tasks.  Somebody (I forgot the name) emailed me and did
bring up the suggestion of modifying task priorities dynamically
to pre-empt and thus achieve the effect of time slicing.  


: The logical conclusion therefore is to save the overhead by allowing
: a task to run until a natural break (eg completion, accept, call, etc).

: Yes, it would be nice to have true multi-tasking.

Well others did manage to do it, so I had assumed that GNAT
was the same.  Still it's a shame not having tasks that
time slice, I mean it doesn't really seem all that big a
deal to have tasking when they don't appear to run
concurrently.  Entries into them and all are allright,
but still without time slicing...


: Sorry if this sounds harsh, it is designed to entertain.  Of course,
: I have yet to meet a programmer who didn't have a unique sence of humor.


Np.

Thanks for the response.


--
Spasmo
"Here's a present just for you
When you open it, you'll be through"
	"Letter Bomb" by the Circle Jerks

Re: Concurrency in Gnat 3.05?

[Spasmo]

Robert Dewar (dewar@cs.nyu.edu) wrote:
: Spasmo said

: Ok, before I get on with my main question, I've got another.  Is
: there any place where I can find some detailed GNAT specific docs?
: I know my questions are simple newbie ones that could be answered
: given some detailed GNAT docs, however all the docs I have seem
: to be about installation, or DJGPP, so I end up wasting bandwidth
: asking newbie questions because I can't seem to find the answers
: anywhere.  Well on to my next newbie question :)

:   The current documentation is gnatinfo.txt, which I assume you have read
:   since it is included in all GNAT releases. If not, you have completely
:   missed the primary available documentation!

The sad thing is that I for some reason can't find this file in
my installation!  Probably my fault as usual, but my latest
screwup is a doozy!  I'll see about re-leeching some of
the files to my shell account and extracting the gnatinfo
from there and downloading.  


: 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?

:   Of course it is not truly concurrent, there is no such thing as true
:   concurrency on a monoprocessor! The processor can only do one thing
:   at a time! What you are asking is whether it time slices among equal
:   priority tasks, and the answer is that it does not, and that Ada 95
:   dispatching semantics does not permit time slicing in its default:
:   The following is from RM annex D.

*Nod*, I managed to pick a really bad choice of words to describe
what I meant.  What I did mean is time slicing, interleaving
task execution times, etc...  Sorta like on Linux with separate
processes and the like. 


: 4   Task dispatching is the process by which one ready task is selected for
: execution on a processor.  This selection is done at certain points during
: the execution of a task called task dispatching points.  A task reaches a
: task dispatching point whenever it becomes blocked, and whenever it becomes
: ready.  In addition, the completion of an accept_statement (see 9.5.2), and
: task termination are task dispatching points for the executing task.  Other
: task dispatching points are defined throughout this Annex.

:   Time slicing is available when GNAT runs over some operating systems where
:   tasks are mapped to threads, and the threads provide time slicing (whether
:   this conforms to annex D is an interesting question .. it certainly does
:   not conform to the spirit of annex D, but you can argue that you are
:   simulating the effect of a multi-processor.

Ok gotcha.


:   In any case, the bottom line is that tasks do NOT time slice on DOS, and
:   any Ada program that depends on time slicing is not portable, and is
:   depending on implementation specific alternative scheduling policies.

Well I've sorta resigned myself to that fact, but it doesn't bug
me too much because in a way this is kinda good.  I mean for the
stuff I'm currently trying to write, time slicing isn't all
that meaningful, but making certain chunks of code "atomic"
is, and so using entry points that encapsulate those portions
enables me to interleave tasks based on units of work which
for me is more sensible and as you state above it would be
more portable, not that this program is anywhere near portable :).
(You should see how many conio functions I'm importing for
this baby, heheheeh).

Thanks for everyone who contributed this thread and my apologies
for my abuse of the above terminology.


--
Spasmo
"Here's a present just for you
When you open it, you'll be through"
	"Letter Bomb" by the Circle Jerks

Re: Concurrency in Gnat 3.05?

[Tucker Taft]

Spasmo (cosc19z5@Bayou.UH.EDU) wrote:

: Robert Dewar (dewar@cs.nyu.edu) wrote:
: ...
: :   Of course it is not truly concurrent, there is no such thing as true
: :   concurrency on a monoprocessor! 

In the Ada 95 reference manual (RM95 9.0(11)), we adopted the term 
"concurrency" to mean (software) multitasking, and "parallelism" to 
mean (hardware) multiprocessing.  I doubt if there is any official 
distinction between these two, but I have read a number of books that 
adopt this convention, or something close to it.  However, when one 
says "true concurrency" I will admit the distinction is probably lost.

In any case, as was pointed out, the most obvious problem is probably the
lack of overlapping of DOS I/O with task execution, which is almost certainly
inherent in the implementation of DOS.  One could implement periodic
polling, perhaps, to accomplish the goal for terminal input, but I presume 
there are limits to the energy willing to be devoted to DOS-based tasking.

: Spasmo

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Concurrency in Gnat 3.05?

[Jon S Anthony]

In article <4smktd$phu@masala.cc.uh.edu> cosc19z5@Bayou.UH.EDU (Spasmo) writes:

> Ok, Time slicing -- whatever :).  Still, with Linux I could easily
> write C programs that used time slicing on my processor courtesy

The point is that time slicing behavior is system dependent.  For
example, GNAT on Solaris maps tasks to threads and they will behave as
you were expecting (switching context for IO, etc.).  I believe that
GNAT for Linux will do this too (I think the P-threads impl to which
tasks are mapped on Linux are "real" threads in this sense - but I'm
not sure).  Actually, GNAT running on anything with native threads
will probably work this way.  For example, GNAT for Win95 and NT maps
tasks to Win95 and NT threads and this should again give you what you
expect.  Actually, that brings up another point.  Since you have Win95
why are you running the DOS version of GNAT under a DOS window instead
of just using the native Win95?

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Concurrency in Gnat 3.05?

[Michael Feldman]

In article <4sjqte$3mu@masala.cc.uh.edu>, Spasmo <cosc19z5@Bayou.UH.EDU> wrote:
>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?

Hmmm - since you have access to my Two_Tasks program, you oughta try
Two_Cooperating_Tasks in the same distribution (or book) in which
DELAY is used to cause the tasks to cooperatively swap control.

The term "multitasking" seems to be one of the least well understood
by the most people, especially in the Ada context.

_Preemptive_ multitasking is NOT required in the Ada 95 core language,
nor is time-slicing. 

Further, "truly" concurrent is possible only if you have
multiple processors. A typical single processor can execute only one 
instruction at a time (maybe with some I/O overlap), so "true" concurrency
is simply not possible. _All_ concurrency on a single processor is
"logical" (sometimes called pseudo-) concurrency.

Your question then can be re-phrased as,

"Will the OS, or the runtime system, manage my logical concurrency
automatically, or is it up to me to write cooperative tasks?" In Ada, 
the answer is "sometimes." :-)

Mike Feldman

Re: Concurrency in Gnat 3.05?

[Robert Dewar]

Jerry said

"But what you probably wanted to ask is: does GNAT/DOS do multi-tasking ?
The answer, yes. But not pre-emptive tasking, what seems to be what you
expected, but cooperative tasking."


That's wrong, of course GNAT/DOS implements pre-emptive tasking, this is
required by Ada semantics (i.e. when a high priority task becomes ready,
it preempts a low priority running task). This certainly works, or if it
does not, then it is a bug -- well actually that's not quite fair. Priorities
and preemptive tasking are only required by Annex D, not by the core
language.

But in any case, it is I think clearly established by later psts in the
thread (Jerry maybe your newsreader is way behind, or perhaps you are not
following threads before answering) that the issue is time slicing among
tasks of equal priority, which requires preemption of course, but should
not be confused with the issue of whether or not preemptive tasking
is implemented.

Re: Concurrency in Gnat 3.05?

[Robert Dewar]

Jerry said

"You might, but I am not sure if the Win/NT version will map to native threads
under Win95."

It will. 

Re: Concurrency in Gnat 3.05?

[Robert Dewar]

Samuel Tardieu said, replying to spasmo

Spasmo> Is Gnat 3.05 (for DOS) truly concurrent when executing tasks?

AFAIK it's not, but there is nothing in the RM that requires it !


On the contrary, there *is* something in the RM that prohibits it! See
annex D. The default FIFO_Within_Priorities scheduling policy requires
run-till-blocked, and time slicing (which is what we are talking about here)
violates that important requirement!

Of course it is fine to have alternative scheduling policies, but this is
implementation dependent, and an implementation that does not support
the real time annex may indeed implement time slicing by default.

Re: Concurrency in Gnat 3.05?

[Michael Feldman]

In article <dewar.837740961@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:

>That's quite wrong. Serious use of tasking for real-time programs
>generally prefers to completely avoid time slicing. That is why the
>requirement in the real time annex of Ada is that time slicing must
>NOT occur using the default scheduling policy (FIFO_Within_Priorities).

This is interesting, because once again we are left to read between the
lines of the RM. Several Ada 83 implementations - Ada/Ed and
Meridian, to cite two such - explicited provided for time-slicing at
the user's option. 

>Generally time slicing can be made available on many operating systems,
>but it is a bit tricky in DOS, because of limitations in the operating
>system. It certainly would be possible, but since it is not required (in
>fact it is only permitted as an option), it is not a high priority item.

I still find it interesting that this is never stated in the RM, even
as a possibility.  Yes, optional (non-default) dispatching policies
are provided for. And of course, the entire dispatching discussion
has been moved from the Ada 83 Chap. 9 to Annex D.

>If what you want is effective concurrency between multiple threads, there
>are many ways to achieve this in correctly programmed Ada. An Ada program
>that depends on time slicing is non-portable.

I agree, Robert. 

My only quibble is with the need to read about time-slicing in the RM
only between the lines. You said in an earlier post that you're not even
sure whether the threads implementations of GNAT are in conformance
with Annex D, except for the dodge that this "simulates multi-processors."
IMHO, after all the work that went into such a recent RM, one should
not have to guess at these things.:-)

Mike Feldman

Re: Concurrency in Gnat 3.05?

[Michael Feldman]

In article <JSA.96Jul19133310@alexandria>,
Jon S Anthony <jsa@alexandria> wrote:

>The point is that time slicing behavior is system dependent.  

And THAT was the import of Robert Dewar's posts on this subject.
The only way to even approach system-_indepencdent_ behavior
is to assume no time-slicing. That is just as well, IMHO -
it's best to write programs whose behavior you understand, 
not programs whose behavior depends upon an unpredictable
time-slicing scheme in the OS.

That is _easier_ to do with Ada tasking.

>Actually, that brings up another point.  Since you have Win95
>why are you running the DOS version of GNAT under a DOS window instead
>of just using the native Win95?

But it should not matter; the point is the same. Indeed, one's
multitasking program ought to behave in the same way - on an input/
output basis - with or without time-slicing. If it does not, it is
a poorly designed concurrent program.

That program of mine, cited by the original poster, is introduced
in the chapters on concurrency in my texts.  Precisely the point
of that program - as the text explains - is that its behavior
_does_ depend on the presence or absence of time-slicing, and the 
ensuing examples show how to remove the dependency!

Newly updated program distributions are available at 
ftp://ftp.gwu.edu/pub/ada/courses. These distributions contain
an index of the programs in the order they appear in the text,
so you can study them in the proper sequence.

[BLATANT PLUG]
Better to buy the books, of course.:-)

Home pages for the books are at 

http://www.aw.com/cseng/authors/feldman/cs1-ada2e/cs1-ada2e.html
(Ada 95 Problem Solving and Program Design)

http://www.aw.com/cseng/authors/feldman/cs2-ada/cs2-ada.html
(Software Construction and Data Structures with Ada 95)

Both books are available now.

Mike Feldman

Re: Concurrency in Gnat 3.05?

[Michael Feldman]

In article <dewar.837877693@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:

>Of course it is fine to have alternative scheduling policies, but this is
>implementation dependent, and an implementation that does not support
>the real time annex may indeed implement time slicing by default.

As I read D.2.2, nothing seems to prevent an implementation that _does_
support Annex D from implementing time-slicing by default. This
paragraph discusses the language-defined (run-till-blocked) policy,
then a configuration pragma by which the programmer can
specify a dispatching policy, but also says (para. 6) that if no such
pragma is present in a program, the dispatching policy is _unspecified_ 
(RMs word).

I am reading the lines of the RM, not between them. I see nothing in
this paragraph stopping me from interpreting this as "the implementation
can use any dispatching policy it darn well pleases". In particular, I see
no words at all requiring the use of the language-defined policy!
Where are these words?

The RM should not force me to read between its lines.:-)

Mike Feldman

Re: Concurrency in Gnat 3.05?

[Robert Dewar]

Michael said

"_Preemptive_ multitasking is NOT required in the Ada 95 core language,
nor is time-slicing."

The first statement is true, the part after the "nor" is misleading, 
because in fact the core has nothing to say about time slicing, but
the real time annex forbids it. I know I have said this before, but
either Mike's newsreader is slow, or it can bare being said again :-)

Re: Concurrency in Gnat 3.05?

[Jerry van Dijk]

Michael Feldman (mfeldman@seas.gwu.edu) wrote:

: Hmmm - since you have access to my Two_Tasks program, you oughta try
: Two_Cooperating_Tasks in the same distribution (or book) in which
: DELAY is used to cause the tasks to cooperatively swap control.

Mmmm, I do indeed seem to have a problem with the newsreader, checking from
another account I noticed a) I didn't receive all postings and b) not all my
postings went out. Grrrrr.


-- 
-----------------------------------------------------------------------
--  Jerry van Dijk       --   e-mail: jerry@jvdsys.nextjk.stuyts.nl  --
--  Banking Consultant   --              Member Team-Ada             -- 
--  Ordina Finance BV    --    Located at Haarlem, The Netherlands   --

Re: Concurrency in Gnat 3.05?

[Jon S Anthony]

In article <4srvs6$qkl@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:

> with Annex D, except for the dodge that this "simulates multi-processors."
> IMHO, after all the work that went into such a recent RM, one should
> not have to guess at these things.:-)
>             ^^^^^^
> Mike Feldman

Criminey!  Let's not open that can of worms again! :-)

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Concurrency in Gnat 3.05?

[Jon S Anthony]

In article <4ss86l$30v@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:

> >Actually, that brings up another point.  Since you have Win95
> >why are you running the DOS version of GNAT under a DOS window instead
> >of just using the native Win95?
> 
> But it should not matter; the point is the same. Indeed, one's
> multitasking program ought to behave in the same way - on an input/
> output basis - with or without time-slicing. If it does not, it is
> a poorly designed concurrent program.

Yes, sure.  But, I think that in many ways what was being asked about
and expected was the sort of behavior that OS threads implementations
provide.  In particular, that an IO does not block _the program_, only
the task.  From this perspective, while it might not matter wrt to the
correctness of the program if this is true, it definitely matters wrt
to the user of the program and its intended use and possibily even its
usability.  So, whether it "matters" is not simply an issue of
"correctness"...

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Concurrency in Gnat 3.05?

[Jon S Anthony]

In article <dewar.837815167@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:

> Jon said
> 
> "The point is that time slicing behavior is system dependent.  For
> example, GNAT on Solaris maps tasks to threads and they will behave as
> you were expecting (switching context for IO, etc.)"
> 
> Yes, in fact the default behavior on Solaris clearly violates the Ada 95
> standard in that time slicing does occur. We are investigating the use
> of the real time priority levels in Solaris which should make it possible
> to correct this incorrect behavior.

While the language only defines the defaul FIFO policy, could you use
the bit in D.2.2(6) which says that in the absence of a
Task_Dispatching_Policy pragma, the dispatching policy is unspecified
to "justify" this behavior?  Or is this an unrelated thing?


"(6)
       A task dispatching policy specifies the details of task
dispatching that are not covered by the basic task dispatching
model. These rules govern when tasks are inserted into and deleted
from the ready queues, and whether a task is inserted at the head or
the tail of the queue for its active priority. The task dispatching
policy is specified by a Task_Dispatching_Policy configuration
pragma. IF NO SUCH PRAGMA APPEARS IN ANY OF THE PROGRAM UNITS
COMPRISING A PARTITION, THE TASK DISPATCHING POLICY FOR THAT PARTITION
IS UNSPECIFIED." (emphasis mine.../jsa)

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Concurrency in Gnat 3.05?

[Spasmo]

Michael Feldman (mfeldman@seas.gwu.edu) wrote:
: In article <4sjqte$3mu@masala.cc.uh.edu>, Spasmo <cosc19z5@Bayou.UH.EDU> wrote:
: >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?

: Hmmm - since you have access to my Two_Tasks program, you oughta try
: Two_Cooperating_Tasks in the same distribution (or book) in which
: DELAY is used to cause the tasks to cooperatively swap control.

Well I've more or less got a grip on things and am implementing
my own scheduling as folks suggested which is actually a blessing
in disguise IMHO, but I'd love to see your Two_Cooperating_Tasks
program indeed.  I've got a subdirectory chock full of your stuff
so I'll look for it imemdiately.


: The term "multitasking" seems to be one of the least well understood
: by the most people, especially in the Ada context.

While I do understand multitasking I'm as guilty as they get for
misusing that term in the most gruesome of ways.


: _Preemptive_ multitasking is NOT required in the Ada 95 core language,
: nor is time-slicing. 

At this point I know :).  I just saw tasks and immediately a synapse
fired and said "pre-emptive multi-tasking".  I suppose the reason
I assumed time slicing was because I had assumed that tasking was
similar to the fork() system call in UNIX C.  My mistake indeed!



: Further, "truly" concurrent is possible only if you have
: multiple processors. A typical single processor can execute only one 
: instruction at a time (maybe with some I/O overlap), so "true" concurrency
: is simply not possible. _All_ concurrency on a single processor is
: "logical" (sometimes called pseudo-) concurrency.

Well "truly" is another gruesome error on my behalf.  Why I even
said "truly" I will never know, especially since I should know
better.


: Your question then can be re-phrased as,

: "Will the OS, or the runtime system, manage my logical concurrency
: automatically, or is it up to me to write cooperative tasks?" In Ada, 
: the answer is "sometimes." :-)

Perfect!  Hey maybe next time I'll just send you a poorly worded
post and you can write it up for me :)


: Mike Feldman

--
Spasmo
"Here's a present just for you
When you open it, you'll be through"
	"Letter Bomb" by the Circle Jerks

Re: Concurrency in Gnat 3.05?

[Jon S Anthony]

In article <4t47tp$8sr@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:

> In article <JSA.96Jul22171928@alexandria>,
> Jon S Anthony <jsa@alexandria> wrote:
> 
> >Yes, sure.  But, I think that in many ways what was being asked about
> >and expected was the sort of behavior that OS threads implementations
> >provide.  In particular, that an IO does not block _the program_, only
> >the task.  From this perspective, while it might not matter wrt to the
> >correctness of the program if this is true, it definitely matters wrt
> >to the user of the program and its intended use and possibily even its
> >usability.  So, whether it "matters" is not simply an issue of
> >"correctness"...
> 
> Yes, this is a good point. The thread started with a question on GNAT/_DOS_,
> in which I don't think the _threads_ implementation is non-blocking.
> Such an implementation would be hard in DOS. 
> 
> This comes back to Dewar's answer about GNAT being built over whatever
> threads support the OS provides.

Agreed.  This is precisely why I raised the point to the poster (Spasmo,
I think) that since he had Win95 (he was running his DOS as a window
under this) he might find the native version of Gnat for Win95 more
to his liking because it does map to native Win95 threads and they
"do the right thing" in this respect.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Concurrency in Gnat 3.05?

[Jon S Anthony]

 In article <4ss86l$30v@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:
 
> >Actually, that brings up another point.  Since you have Win95
> >why are you running the DOS version of GNAT under a DOS window instead
> >of just using the native Win95?
> 
> But it should not matter; the point is the same. Indeed, one's
> multitasking program ought to behave in the same way - on an input/
> output basis - with or without time-slicing. If it does not, it is
> a poorly designed concurrent program.

Yes, sure.  But, I think that in many ways what was being asked about
and expected was the sort of behavior that OS threads implementations
provide.  In particular, that an IO does not block _the program_, only
the task.  From this perspective, while it might not matter wrt to the
correctness of the program if this is true, it definitely matters wrt
to the user of the program and its intended use and possibily even its
usability.  So, whether it "matters" is not simply an issue of
"correctness"...

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Concurrency in Gnat 3.05?

[Michael Feldman]

In article <JSA.96Jul22171928@alexandria>,
Jon S Anthony <jsa@alexandria> wrote:

>Yes, sure.  But, I think that in many ways what was being asked about
>and expected was the sort of behavior that OS threads implementations
>provide.  In particular, that an IO does not block _the program_, only
>the task.  From this perspective, while it might not matter wrt to the
>correctness of the program if this is true, it definitely matters wrt
>to the user of the program and its intended use and possibily even its
>usability.  So, whether it "matters" is not simply an issue of
>"correctness"...

Yes, this is a good point. The thread started with a question on GNAT/_DOS_,
in which I don't think the _threads_ implementation is non-blocking.
Such an implementation would be hard in DOS. 

This comes back to Dewar's answer about GNAT being built over whatever
threads support the OS provides.

Mike Feldman