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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!acf3!acf2!flynn
From: flynn@acf2.UUCP (Susan Flynn)
Newsgroups: comp.lang.ada
Subject: Simon Tuffs on Tasking, I/O, Priorities and Real-Time Response
Message-ID: <9770015@acf2.UUCP>
Date: 20 Jan 88 17:45:00 GMT
Organization: New York University
List-Id: <comp.lang.ada>


[I am posting this for Simon Tuffs as he is unable to post articles
to the net.  The behaviour of the compilers when priorities are added 
seems legal to me:  A_Task gains control of the CPU at some point
(note that delays are only required to suspend a task for *at least* 
as long as the specified duration), but the system hangs on I/O.  While 
I agree with him that he is not getting real-time responses, there are 
many such situations where it is legal for compilers to behave diffently.
I'm still looking into what the ARG's (previously known as the Ada LMC) 
current stand on scheduling is.  Susan]

From:	NAME: P. S. TUFFS                   
	FUNC: PCCT (16)               
	TEL: (412) 337 2946       <TUFFS1 AT A1 AT ALDID1>


Susan,

I agree with your comments about the use of a shared variable, the only 
reason for this nasty little construct is to keep the example short.  
The original effort, from which this was abstracted to give the same 
behavior, has lots of tasks, some acting as mailboxes between the 
real-time and user-interface tasks.  I have re-written the example so 
that use is not made of a shared variable, and attached it to the bottom 
of this message. 

I am aware of the problem of accessing an I/O device from two 
unsynchronized tasks, as well as the dangers of using input-output 
routines from _any_ real-time task.  This is a standard no-no in the 
real-time control world from which I come.  The problem I am having is 
that I assumed (incorrectly?) that the designers of an Ada compilation 
system would make every attempt to avoid the blocking problem that I 
came across.

About priorities, all three of the compilers (say that they) implement 
priorities.  On the VAX/VMS system, use of priority without time-slice 
does release the real-time task to run, even without re-assigning 
Ada$input to TT:.  On the Alsys compiler, priority does not help, even 
with time-slice: the real-time task _still_ freezes when the 
first_character of the input string is entered at the keyboard.  (The 
system behaves as I want until that time).  The Meridian system does not 
have a time-slice option, but with the mail-box example below the use of 
priorities does actually allow the "A_Task" to be updated once on each 
rendezvous between the main program and the mail box.  The Meridian 
behavior is still not real-time, however.

As to all the compilers behaving correctly: to me that implies that they 
should all behave the same (on a non-erroneous piece of code, such as 
the gruesome version given below).  This is not the case here.

Thanks for your comments, and please will you forward this to the 
info-ada bulletin board since my system seems to be mailing my outgoing 
stuff to the Great Garbage Collecter in the Net.

Simon Tuffs.

Tuffs@alcoa.com

-------------------------------------------------------------------------

-- An example of how the Text_IO.Get for enumerations can block a task
-- This example is more gruesome, due to the use of a mail-box.
generic 
  type Data is private;
package Mail_Box is
  type Mail_Boxes is limited private;
  procedure Post(The_Data:        in     Data;
                 In_The_Mail_Box: in out Mail_Boxes);
  function Read(From_The_Mail_Box: in  Mail_Boxes) return Data;
  procedure Stop(The_Mail_Box: in out Mail_Boxes);

private
  task type Mail_Boxes is 
    entry Post(The_Data: in  Data);
    entry Read(The_Data: out Data);
    entry Stop;
  end Mail_Boxes;
end Mail_Box;

package body Mail_Box is
  procedure Post(The_Data:        in     Data;
                 In_The_Mail_Box: in out Mail_Boxes) is
  begin
    In_The_Mail_Box.Post(The_Data);
  end Post;

  function Read(From_The_Mail_Box: in  Mail_Boxes) return Data is
    The_Data: Data;
  begin
    From_The_Mail_Box.Read(The_Data);
    return The_Data;
  end Read;

  procedure Stop(The_Mail_Box: in out Mail_Boxes) is
  begin
    The_Mail_Box.Stop;
  end Stop;

  task body Mail_Boxes is
    Local_Data: Data;
    Was_Stopped_Prematurely: Boolean := False;
  begin
    -- Force the user to post some data before accepting read requests.
    -- Note that a call to Read will be suspended until some data is posted.
    --
    select
      accept Post(The_Data: in Data) do
        Local_Data := The_Data;
      end Post;
    or
      accept Stop;
      Was_Stopped_Prematurely := True;
    end select;
    if not Was_Stopped_Prematurely then
      loop
        select
          accept Post(The_Data: in  Data) do
            Local_Data := The_Data;
  	  end Post;
        or
	  accept Read(The_Data: out Data) do
	    The_Data := Local_Data;
	  end Read;
        or
          accept Stop;
          exit;
        or
	  terminate;
        end select;
      end loop;
    end if;
  end Mail_Boxes; 
end Mail_Box;

with Text_Io;
with Mail_Box;
procedure Task_Blk is
  type Data is new Integer;
  package Mail is new Mail_Box(Data);
  The_Mail_Box: Mail.Mail_Boxes;

  task A_Task is
    entry Start;
    entry Stop;
    pragma priority(10);
  end A_Task;

  type Commands is (Help, Stop);
  The_Command: Commands;
  package Command_Io is new Text_Io.Enumeration_IO(Commands);

  task body A_Task is
    Local_Data: Data := 0;
  begin 
    accept Start;
    Mail.Post(Local_Data, The_Mail_Box);
    loop
      select
        accept Stop;
        exit;
      or
        delay 0.1;
        Local_Data := Mail.Read(The_Mail_Box);
        Local_Data := Local_Data + 1;
        Mail.Post(Local_Data, The_Mail_Box);
      end select;
    end loop;
  end A_Task;

begin
  -- The mail box is implicitly started, and is awaiting Post.
  -- The A_Task satisfies the Post, and we are free to run.
  A_Task.Start;

  -- Update the user interface.
  declare
    Local_Data: Data;
  begin
    loop
      Text_IO.Put("Enter the command: ");
      Command_IO.Get(The_Command);
      exit when The_Command = Stop;
      Local_Data := Mail.Read(The_Mail_Box);
      Text_Io.Put("The variable is: " );   
      Text_Io.Put_Line(Data'Image(Local_Data));
    end loop;    
  end;

  -- Clean up the system.
  A_Task.Stop;
  Mail.Stop(The_Mail_Box);
end Task_Blk;





Relay-Version: version nyu B notes v1.5 12/10/84; site acf3.NYU.EDU
From: eds9305@acf3.NYU.EDU (Eric Shafto)
Date: 20-Jan-88 08:48 EST
Date-Received: 20-Jan-88 08:48 EST
Subject: Re: D&D BANNED IN FREMONT, CA.
Message-ID: <22180006@acf3.NYU.EDU>
Path: acf3!eds9305
Newsgroups: rec.games.frp
Posting-Version: version nyu B notes v1.5 12/10/84; site acf3.NYU.EDU
Organization: New York University
References: <239@bacchus.DEC.COM>

Along with the general discussion of banning D&D:

It has been said that the FRP's could cause an [obsessive,
unhappy, addictive] personality to suffer emotional damage,
presumably by becoming obsessed with his character at the
expense of reality.

I see at least that much danger from fantasy *books*.  How
many of us here stayed up past our bedtimes with a flashlight
and the Hobbit? (or SF or mysteries, or whatever).

You can't ban fantasy.  You can't (or shouldn't) ban literature.
You should look for unhappy children who withdraw from the world
and try to help them, but you shouldn't try to ban a game.

I don't believe that is why the principal did it, by the way.
I'm sure it was on religious or moral fear.

Regards,
Eric Shafto
eric@xp.psych.nyu.edu

Relay-Version: version nyu B notes v1.5 12/10/84; site acf3.NYU.EDU
From: eds9305@acf3.NYU.EDU (Eric Shafto)
Date: 20-Jan-88 08:56 EST
Date-Received: 20-Jan-88 08:56 EST
Subject: Re: DM question
Message-ID: <22180007@acf3.NYU.EDU>
Path: acf3!eds9305
Newsgroups: rec.games.frp
Posting-Version: version nyu B notes v1.5 12/10/84; site acf3.NYU.EDU
Organization: New York University
References: <6255@cisunx.UUCP>

 jgsst3@cisunx.UUCP (John G. Schmid) writes:

>>3. Clerics should be able to use swords. I would think that a mace does
>>more damage through crushing than a sword through cutting.
>
>i agree completely the historical cleric (for the most part) had no
>compunctions about using an edged weapon.  i think the blame for this
>stricture can be laid at the feet of E.Gary Gygax who inserted it for
>play balance reasons.  i.e. give a cleric a sword and he would be almost
>as good a damage doer as a fighter, thereby why choose to be a fighter
>when you can have spells too as a cleric.

Actually, in the Crusades, it was quite common that a 'man of God'
would refuse to use weapons designed to shed blood, intending 
instead to convince the infidel by bashing and smashing.  To this
end a series of nasty weapons were devised (unfortunately, quadrelle
and mace are the only ones that come to mind -- oh yes, how could
I forget, the flail, which was superior to the mace in that it did
2d4 damage to larger than man-sized creatures :-) )

Regards,
Eric Shafto
eric@xp.psych.nyu.edu