From: ganek@apollo.hp.com (Dan Ganek)
Subject: Egg on Face (was Re: Favourite DOMAIN/OS features (or mis-features))
Date: Fri, 24 Jul 1992 13:23:06 GMT
Organization: Hewlett-Packard Corporation, Chelmsford, MA
Keywords:  Eventcounts



Sigh..... A few days ago I posted an article on the correct
way to program eventcounts and as is usually when I
do such a thing, I screwed up. (HP-UX makes eventcount
programming so much easier :-)   So as not to make a 
greater fool of myself, I just post mail I recevied from
Lawrence T. Hoff of Brookhaven.  He not only corrects
my mistake but also gives the alternate way of using event
count (i.e. incrementing the ec value by one instead of using 
ec2_$read)
 
Thanks Laurence, I hope you don't mind.
           
/dan ganek

---BEGIN----

    Received:  from bnlux1.bnl.gov by amway.ch.apollo.hp.com id <AA02315@amway.ch.apollo.hp.com> Thu, 23 Jul 92 17:13:57 EDT
    Received:  by bnlux1.bnl.gov (5.57/Ultrix3.0-C)
               id AA11185; Thu, 23 Jul 92 17:12:33 -0400
        Date:  Thursday, July 23, 1992   5:16:35 pm (EDT)
  X-Bad-Date:  Thu, 23 Jul 92 17:12:33 -0400
        From:  hoff@bnlux1.bnl.gov (Lawrence T. Hoff)
          To:  ganek@apollo.hp.com
     Subject:  Re: Favourite DOMAIN/OS features (or mis-features)
  Newsgroups:  comp.sys.apollo
 In-Reply-To:  <BrsrGA.DL8@apollo.hp.com>
  References:  <1992Jul20.093747.12417@wam.umd.edu> <Brozvu.5uu@apollo.hp.com> <1992Jul22.063333.4659@wam.umd.edu>
Organization:  Brookhaven National Laboratory, Upton, NY 11973

In article <BrsrGA.DL8@apollo.hp.com> you write:
>
>Second, keeping in mind that I haven't seen the code nor do I have ANY
>idea of the expertise of the author, but this sound like the classic 
>mistake that EVERYONE seems to make when first using eventcounts. (Yours
>truely included). i.e.
>

The idea of a 'volatile' value, which can change between statements of sequential
code seems to cause much anxiety among work-station programmers. Folks who
come from a real-time (multi-threaded, w/asynchronous external events ) programming 
background seem to do just fine, tho.


>instead of the correct sequence, or some CYCLIC variation thereof
>   
>    REPEAT
>      ec2_$wait(..);
>      ec2_$read(..);
>      xxx_$cond_event_wait(...);       
>      process_event(...);
>      UNTIL tired;
>
>the programmer uses something like::
>
>    REPEAT
>      ec2_$wait(..);
>      xxx_$cond_event_wait(...);       
>      {an event can be queued HERE before the ec2_$read but after the cond_event_wait}
>      ec2_$read(..);                   
>      process_event(...);
>      UNTIL tired;  
>

	Ummmmmm, good thing you're not going to have to program ec stuff anymore,
you *still* don't have it right. ;-) Actually, your code would work *if*
process_event() dequeued *all* the pending events, *and* didn't choke if there
were no events. In this case it should be called something like process_all_events().

Try :

	REPEAT
          ec2_$wait(..);
	  ec2_$read(..); // to use as new trigger value (+1)
	    WHILE (xxx_$cond_event_wait(..))  // must be conditional, because we're 
                                              // *still*  allowing a race condition if 
                                              // new events are queued during processing.
		    process_event(..);
	  UNTIL tired;

Or (better yet) :

	REPEAT
	  ec2_$wait(..);
	  ec2_$read(..); // to use as new trigger value *and* to determine now many 
                         // events to process (new trigger value - old trigger value).

	     WHILE (number_of_events_to_process)
		number_of_events_to_process -= process_event(..);

		// process_events returns the number of events processed, i.e.
		// the number of bytes read from a byte stream or mbx, or always 1
		// for gpr, dialog, unbuffered I/O, datagram events, or other events
                // which are typically handled one at a time.

		// Notice how nothing needs to be 'conditional'

	  UNTIL tired;

Or (even better, but only useful for events which are best handled one at a time)

	REPEAT
	  ec2_$wait(..);
	  trigger_value++; // don't even read the new value, eliminate any chance
			   // for a race condition, there's no need for anything
                           // conditional or any looping dequeuing routines.
	  process_single_event(..);


And while we're on the subject, my favorite Domain-ism is/was the variant link.
UNIX users essentially *use* the equivalent of variant links in constructions like :

/bin.`arch`

but it's not *quite* the same.-- 

----ENDOFMAIL----
Newsgroups: comp.sys.apollo