Interrupt "Get"

Interrupt "Get"

[John Slavich]

Hello Again,

	Being a novice, I'm trying to find an easy way of interrupting a get
command.  Let's say that I have two tasks and Task_1 has the first
rendez-vous ans has a "get":
---
accept get_num(num: in out Integer) do
	put("Type a number");
	get(num);
---

Task_2 has to wait until the user enters a number.  In essence
everything is frozen until the number is entered.  Is there a way that I
can still wait for the user's answer and allow task_2 to go ahead?

Thanks for your time.

JOhn

Re: Interrupt "Get"

[Robert Dewar]

<<Sorry John -- as you have stated the problem the answer is no. If there are
only
two tasks then the critical region of task_1 (the part following the "do"
and down to
the end of the rendezvous) will execute at the same priority as the
"calling" task. As
a result the CPU will not be available to task_2 (the "calling" task). Of
course there
are always some possibilities. The simplest is to remove the "do",  and then
if
your ada compiler supports time slicing both tasks can continue to execute.
>>


This is misleading. In any implementation of Ada where tasks map to
operating systems threads, and any reasonable operating system, the
I/O call will block the task that executes it, but not other tasks.
This answer is written from the narrow perspective of an Ada
implkementation in which operating systems threads are not used,
but these days, use of operating systems threads is the normal case,
or at least is an option (e.g. in GNAT, we provide both OS threads,
and user level threads, because both are useful in some contexts).

Note that relying on time slicing is not appropriate. Indeed the only
defined dispatching protocol in Ada 95 absolutely *forbids* time
slicing on a single processor.

Once again, if you are using an obsolete operating system like DOS that
does not provide any kind of operating system threads support, yes, indeed
I/O (and anything else) will block all tasks and there is no easy way around
this problem, although it is easy enough to special case keyboard I/O (the
Alsys compilers for DOS did this, I wrote the code that was needed :-)
However, this was not done in the old ACT version of DOS, which is no longer
supported. It is possible that the volunteer version of DOS that someone or
other is working on may have had this feature added.

Re: Interrupt "Get"

[Michael F Brenner]

Robert > Once again, if you are using an obsolete 
       > operating system like DOS that
       > does not provide any kind of operating system threads support, 
       > yes, indeed I/O (and anything else) will block all tasks and 
       > there is no easy way around this problem, although 
       > it is easy enough 
       > to special case keyboard I/O (the
       > Alsys compilers for DOS did this, I wrote the code that was needed :-)
       > However, this was not done in the old ACT version of DOS, 
       > which is no longer supported. It is possible that 
       > the volunteer version of DOS that someone or
       > other is working on may have had this feature added.
  
I certainly agree: it is easy enough to special case certain
devices. As a matter of fact, the lack of special casing five
particular devices (keyboard, TCP, disk, mouse, and Rs232) is what
has led many people to believe that Ada tasking does not work at all,
in any operating system.

Who hasn't tried a tiny task with a text_io get in it and been
disappointed in the results?

It would be more fair to conclude that the Ada runtime
libraries were poor. But people seldom express the problem this way.

In general, the runtime source codes have not been made available
(gnat, of course, excepted) at a reasonable cost. Therefore, it was
easy to assume tasking itself was causing the blocking.

We should be aware of this false belief, that the bug is in the
tasking. Awareness could help better explain the problem to those
experiencing the blocking.

As my DOS computer backs up a drive, I am watching two drives
working in parallel with overlapped, non-blocking track I/O using
direct control of the disk device driver, and at the same time
responding to keystrokes. AA

The DOS system is a combination of three levels: the shell calls (interrupt
21), the BIOS, and the BDOS. There is no contradiction in an Ada
runtime library using techniques under an operating system's 
Shell level (or under the VMS record manager, or whatever is blocking).

Similarly, there is no contradiction in going OVER the operating
system and adding virtual memory and/or threads (as most DOS Ada 
compilers do). 

In my opinion, a runtime library that implements text_io or stream_io
in a manner that blocks in a task could use some improvement.

Mike

Re: Interrupt "Get"

[Robert Dewar]

John said

<<Task_2 has to wait until the user enters a number.  In essence
everything is frozen until the number is entered.  Is there a way that I
can still wait for the user's answer and allow task_2 to go ahead?

Thanks for your time.
>>

Most implementations of Ada 95 should at least have the option of 
overlapping computation with waiting for keyboard input. This is
certainly implementation dependent, and for example, something like
the old obsolete DOS version of GNAT does not provide concurrency
at the OS level (because DOS does not!)

You need to tell people exactly what system you are using, what machine,
what operating system etc.

Re: Interrupt "Get"

[John Slavich]

Robert Dewar wrote:
> 
> John said
> 
> <<Task_2 has to wait until the user enters a number.  In essence
> everything is frozen until the number is entered.  Is there a way that I
> can still wait for the user's answer and allow task_2 to go ahead?
...
> You need to tell people exactly what system you are using, what machine,
> what operating system etc.

	I did it again.  I'm using GNAT 3.1 for Win 95 on a pentium 233.  As I
first mentionned (which Dale confirmed), because of Task_1, everything
is frozen for the user's input.  I'm trying do find out if I can give a
time limit for the user to enter a value.

John

Re: Interrupt "Get"

[Robert Dewar]

Matthew said

<<Are you taking about a floating point divide or a fixed point divide?  They
are very different!

I'm confused by your answer, because a fixed point divide returns universal
fixed. How does one get a divide by zero exception, since 1) we've proven z
is in fact not zero, and 2) the universal fixed result has infinate range?
>>

Now we are carrying legalisms to the point of absurdity. The description
in the RM that the result is universal fixed is for semantic description
purposes only, it has nothing at all to do with the actual code, which
obviously does not produce a universal fixed result.

Matthew, you seem to think that the code actually reflects the RM, i.e.
that you first do a universal fixed division, and then a subtype conversion.
A little thought will show you that this is entirely impractical, and that
of course in practice, the generated code involves scaling operations and
multiplications and divisions that are *equivalent to* to the result of
first doing a universal fixed division and then doing the subtype conversion.

I guess that's what is confusing you here!!!!

In fact the comment about division by zero is exactly right, thankyou Simon
for pointing this out. It is not immediately obvious that this is the case
(this case cannot arise for example for normal integer division except in
very peculiar cases).

But consider, let's use decimal, it's easier

we want to divide 5.15 by 3.00

the representations are 515 and 300, but of course we cannot compute
the result as

   result = 515/300 * 100 

since that would lose precision. Instead we compute

   result = (100 * 515) / 300

Now in general this scaling means the numerator is double length, and it
can definitely occur that the most significant word of this double length
result is greater than the dividend, which is the condition for integer
overflow.

So, it is quite true that if we have a positive scale, which is the normal
case, as in the above (scale here = number of digits after point), then
we can get zero divide even with a non-zero divisor.

The test therefore is not simply a comparison with zero, but a comparison
for an excessively small value, and that is as easy a test to do!

Re: Interrupt "Get"

[Joseph Altea]

ignore


Joseph Altea