Conference 49.910::kav30

29.0. "wait does not satisfy" by SORGEN::HERMANN () Tue Oct 15 1991 14:14

{
  this program demonstrates a problem with timeouts in connection with
  (timer) ast's

  the main program starts a timer in repeat mode and suspends itself with
  wait_any for 10 seconds. the ast routine writes to the console once a
  second. one expects that the program stops after 10 seconds or in other
  words after 10 messages on the console,but it continues for ever.
  it looks like that the timeout is always set back to 10 seconds after 
  each delivered ast!
  the ast routine has to stop the timer in order to satisfy the wait. 

  tested workaround : use absolute time values instead of interval!

  Hermann Mueller,RTEC Munich
    
}
MODULE kav_timers;

INCLUDE $kavdef;
INCLUDE $get_message_text;
INCLUDE $kernelmsg;
INCLUDE $elnmsg;

VAR ast_counter : INTEGER;
    tmr_cnt     : INTEGER;
    ten_seconds : LARGE_INTEGER;    
    dummy       : INTEGER;

PROCEDURE tmr_ast;
BEGIN
    WRITELN('Timer has expired!');
    ast_counter := ast_counter + 1;
    IF ( ast_counter >= 20 )
      THEN  BEGIN stop_tmr(tmr_cnt);
    END;
END;

PROCEDURE error_text(status : INTEGER);
VAR
    outstr : VARYING_STRING(255);
BEGIN
    ELN$GET_STATUS_TEXT(status
	,[STATUS$FACILITY,STATUS$SEVERITY,STATUS$IDENT,STATUS$TEXT]
	,outstr);
    WRITELN(outstr);
END;	

PROCEDURE init_tmr(tmr_cnt : INTEGER);
VAR
    status : INTEGER;
BEGIN
    KAV$TIMERS(status
	,KAV$M_RESET_TMR
	,KAV$K_CTMR1
	,tmr_cnt
	,ADDRESS(tmr_ast));
    IF (status<>KER$_SUCCESS) THEN BEGIN
	error_text(status);
	EXIT;
    END;
END;

PROCEDURE start_tmr(tmr_cnt : INTEGER);
VAR
    status : INTEGER;
BEGIN
    KAV$TIMERS(status
	,KAV$M_LOAD_TMR_CNT + KAV$M_START_TMR + KAV$M_REPEAT_TMR 
	,KAV$K_CTMR1
	,tmr_cnt
	,ADDRESS(tmr_ast));
    IF (status<>KER$_SUCCESS) THEN BEGIN
	error_text(status);
	EXIT;
    END;
end;

PROCEDURE stop_tmr(var tmr_cnt : INTEGER);
VAR
    status : INTEGER;
BEGIN
    KAV$TIMERS(status
	,KAV$M_STOP_TMR
	,KAV$K_CTMR1
	,tmr_cnt
	,ADDRESS(tmr_ast));
    IF (status<>KER$_SUCCESS) THEN BEGIN
	error_text(status);
	EXIT;
    END;
END;

PROGRAM main(OUTPUT);
CONST
    tmr_preset = 2500;
    tmr_count  = 999;
    tmr_shift  = 65536;
begin 
    ast_counter := 0;
    tmr_cnt := tmr_count * tmr_shift + tmr_preset;
    ten_seconds := TIME_VALUE('0000 00:00:10.00');
    init_tmr(tmr_cnt);
    start_tmr(tmr_cnt);

    {* your code starts here *}
    WAIT_ANY(TIME := ten_seconds);
    {* your code stops here *}

     stop_tmr(tmr_cnt);
end;

end.

Hermann,

	this scenario you mention in 29.0 is known. The reason is
as follows:

	o The ELN system puts the process in the wait state, with a
	  delta time of 10 seconds(in your case).

	o The AST delivery code gets triggered due to an AST queuing,
	  the code "wakes" up the process, to execute the AST routine.

	o Once the process gets "waken", its starts execute, but just
	  before the AST interrupt occurs, which starts the AST 
	  delivery, which leads to start the AST routine.

	o After the AST routine(ie. after RET), the AST delivery code
	  gets control again, which will start to execute the 
	  "interrupted" instruction. This instruction in this case is
	  a BLBS on R0, which causes the branch to be taken. This
	  branch takes it to the start of WAIT_ANY, which will  be
	  re-executed, therefore the delta timeout NEVER occurs!

Hope this helps,

-Jan

    jan,
    >> hope this helps....
    not quite, i (almost) understood the reason for this...what we (service-
    wise) need to know is wether this is or will be documented (you say this is
    a known restriction) or will be fixed in a future release?
    thanks hermann

Hermann,

>>>	...what we (service wise) need to know is wether this is or will be 
>>>	documented (you say this is a known restriction) or will be fixed 
>>>	in a future release?

	To be honest, I do not know if this is or will be documented. You better
	ask Thomas Lemmer. The fact is that this will (most likly) not be fixed.
	Its the way ELN works. Somebody needs to request this change to the 
	ELN engineering.

Hope it cleared up more...? At least you know the reason behind it.

-Jan

	Just as a sanity check...

	Would a reasonable workaround be to calculate an absolute time
	for the wait_any timeout?

	Mike

    
    that's what i told my customer.... (it works too)
    
    hermann