From: ken@cs.cornell.edu (Ken Birman)
Subject: Re: How does isis_timeout() work?
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Distribution: na
Date: Fri, 9 Oct 1992 16:49:37 GMT

In article <98112@bu.edu> hss@bigbird.bu.edu (Himanshu Sinha) writes:
>
>I have a function "do_something()" called by several other functions in my
>program. I want to ensure that if this function has not been called by anyone
>in the last 5 seconds then it should be called. I call isis_timeout() in
>do_something() to take care of this.
>__________________________________________________________________
>/* tid is a global variable that was initially set by a call to isis_timeout*/
>do_something()
>{
>    isis_timeout_cancel(tid);
>        ........
>        .......
>	((do asynchronous abcasts and fbcasts here ))
>    tid = isis_timeout(5000, do_something, NULL, NULL)
>}

OK, but one warning: do_something will NOT be run as a task in this
case because isis_timeout is not really an official interface and
we use it so much that we didn't want to pay the cost of a t_fork.
So, your do_something routine is running on somebody else's stack.
This makes the code unsafe -- you shouldn't issue broadcasts in a
routine that runs from isis_timeout -- because they block sometimes,
asynchronous or not.

So... I think you want to change this to:
     tid = isis_timeout(5000, t_fork, (vfunc*)do_something, NULL);

>However, this does not always work. Somewhere in my program I have the
>following loop.
>
>	while(condition)
>	isis_accept_events(ISIS_ASYNC);
>	....................
>
>The do_something() function does not get called for a long time while the
>program is in this loop. It does get called - but not every 5 seconds.
>Sometimes it does not get called for a few minutes.

Well, how do you know that the loop runs while the several minutes are
elapsing?  Maybe other things in your program are keeping the system 
very busy, and so the timeout queue doesn't get serviced?

Even more likely: maybe congestion or something causes the asynchronous
multicasts in your do_something routine to block, and the timeout is
actually not "pending" when you see these long delays?

Basically, isis_timeout is not quite the sort of realtime mechanism you
apparently are thinking of it as being.  What it really does is to add
an event to the timeout queue, and next time Isis looks at the queue, it
will perform the operation if the time has expired.  Since you didn't
say anything about time-warp messages, when Isis does dequeue these
operations they are within a few seconds of the scheduled time.  You
should probably be asking yourself why isis_timeout didn't get called
for so long in some cases...

>Another question I have is about the flow of control. The manual says that no
>task is created and only a function call is made. Where (in my program) is the
>call to do_something() made from?

It is probably made by the ISIS scheduler itself, as a procedure call from
the scheduler loop -- something called run_isis().

-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428