Immediate Reading in Tasks

Immediate Reading in Tasks

[George C. Harrison, Norfolk State University]

Ada teachers and Real-Time types - 

  I'd like some helpful hints about how to handle an "immediate get" type of
procedure in a tasking environment.  By "immediate get" (IGET) I mean the
ability to read a character directly from the keyboard without pressing the
return key.  Some, if not most, implementations of Ada have the ability to do
such a reading albeit indirectly.

Here's the "problem."  

Doing an IGET inside a task generally causes the other tasks to wait until the
user presses a key.  In my real time simulations for my students when they must
act as monitors or interrups it would be nice to have the program run with all
its tasks until a key is pressed (and then read, if necessary).

Do-While Jones in "Ada in Action" proposes a solution similar to the following:

Define a function KEYPRESSED (boolean) and an IGET procedure that only works
when KEYPRESSED is TRUE.  These subroutines call a task which essentially holds
the incoming character as the value of a local [task] variable, setting
KEYPRESSED to true until the character is retrieved from the task.

So another task might do this:

loop
  do_stuff;
  if keypressed then
    iget(ch);
    do_something_with_ch;
  else
    do_something_else;
  end if;
end loop;


I welcome any and all ideas.  I have used the Do-While Jones method, but it
seems to have a lot of overhead.  

George

-- George C. Harrison                              -----------------------
----- Professor of Computer Science                -----------------------
----- Norfolk State University                     -----------------------
----- 2401 Corprew Avenue, Norfolk, Virginia 23504 -----------------------
----- INTERNET:  g_harrison@vger.nsu.edu ---------------------------------

Re: Immediate Reading in Tasks

[William Loftus]

In article <739.27e1226c@vger.nsu.edu> g_harrison@vger.nsu.edu (George C. Harrison, Norfolk State University) writes:
>Ada teachers and Real-Time types - 
>
>Do-While Jones in "Ada in Action" proposes a solution similar to the following:
>
>Define a function KEYPRESSED (boolean) and an IGET procedure that only works
>when KEYPRESSED is TRUE.  These subroutines call a task which essentially holds
>the incoming character as the value of a local [task] variable, setting
>KEYPRESSED to true until the character is retrieved from the task.
>
>So another task might do this:
>
>loop
>  do_stuff;
>  if keypressed then
>    iget(ch);
>    do_something_with_ch;
>  else
>    do_something_else;
>  end if;
>end loop;
>
>I welcome any and all ideas.  I have used the Do-While Jones method, but it
>seems to have a lot of overhead.  

It does have a lot of overhead.  In many real-time systems the cost of
executing "keypressed" is too much.  If the call to keypressed is 100ms and
you need to process a user typing (i.e.  ~50 wpm) and other information you
are devoting 1/2 sec/sec to processing keystrokes (these numbers come from
a project that I am currently working on).  Fortunately, keystrokes are
often interrupts, and many Ada systems allow the mapping of interrupts to
task entries.  Using this approach the task (see below for a quick example)
waits (allowing other tasks to execute) for a rendezvous from the system
software and is not constantly polling for keystroke availability.

task Keystroke is
   entry Key (Code : Byte);
end Keystroke;

task body Keystroke is
   Stroke : Byte;
begin
   loop
     accept Key (Code : Byte) do
        Stroke := Code;
     end accept;
     Rest_Of_System.Process_Keystroke (Stroke);
   end loop;
end Keystroke;

--
William Loftus                   (215) 668 3661
WPL Laboratories, Inc.           UUCP: loftus@wpllabs.UUCP
P.O. Box 111                     ARPA: loftus!wpllabs@prc.unisys.com
216 Wynne Lane
Penn Valley, PA 19072            Ada and Unix Software Consultants

Use clauses in the visible parts of packages???

[Scott Layson Burson]

So here I am implementing an Ada front end (for an analysis system,
not a compiler) and I'm working on use clauses, and I seem to have
found a case which is not mentioned in the manual, nor can I find any
mention of it in the commentaries.  To wit: what happens if a use
clause appears among the basic declarative items in the visible part
of a package specification?  Do the identifiers made directly visible
by the use clause become part of the package's visible declarations?

Now, it seems to me that either:

 1) The use clause does augment the package's visible declarations,
    and this is not the slightest bit problematic -- the various
    existing rules cover the fine points of the situation perfectly
    well.  This seems unlikely, because it's the kind of thing the LRM
    would typically include a helpful note about.

 2) Despite the fact that the syntax allows use clauses in visible
    parts of packages, nobody but me has ever actually thought of
    putting one there.  This seems unlikely because of the amount of
    time people have spent poring over the specification and the
    number of extant implementations.

 3) The relevant rules are in the LRM or commentaries somewhere, but
    I haven't found them.  This seems unlikely because there aren't
    many places in the manual where I would expect to find such rules,
    and grepping through the commentaries turns up a short list of
    instances of "use clause", among which I have found no reference
    to this possibility.

Can anyone help me out?

-- Scott Burson
Gyro@Reasoning.COM

Re: Use clauses in the visible parts of packages???

[Fred Stluka]

In article <1991Mar27.200047.21167@kestrel.edu> Gyro@Reasoning.COM writes:
> ... To wit: what happens if a use
> clause appears among the basic declarative items in the visible part
> of a package specification?  Do the identifiers made directly visible
> by the use clause become part of the package's visible declarations?

No.  The identifiers are only made visible to the "scope" of 
the use clause, which does not include other packages which 
"with" the package containing the use clause.

Section 8.4(4) says:

     In order to define which declarations are made directly visible 
     at a given place by use clauses, consider the set of packages
     named by all use clauses whose scopes enclose this place...
                                           ^^^^^^^

The "scope" of a use clause is defined in 8.4(3) as:

     For each use clause, there is a certain region of text called
     the "scope" of the use clause.  This region starts immediately
     after the use clause.  If the use clause is a declarative item 
     of some declarative region, the scope of the clause extends to
     the end of the declarative region. ...

--Fred

-- 

Fred Stluka                              Internet: stluka@software.org
Software Productivity Consortium         UUNET:    ...!uunet!software!stluka
2214 Rock Hill Rd, Herndon VA 22070 USA