Dear Michael,
first of all, for keeping track of the changes I recommend to look into
the Mantis "TTCN-3 Change Requests" sub-projects
(
www.ttcn3.org/ChangeRequest.htm). The ETSI TTCN-3 maintenance
team is forced to work on a Change Request (CR) basis and all changes
are documented in these sub-projects, in most cases by copying the parts
to be changed into a Word File and by using change bars to document the
changes. One exception to this are the figures of the operational
semantics because figures and change bars do not work properly together
(or I am not able to handle it properly).
The number of the CR to which you seem to refer is 2151.
If you look into the documents with the change bars attached the CR2151
you will recognize that in the Core Language Document only Section 23
"Timer Operations" has changed and that the changes are related to the
semantics of ANY and ALL. All other parts of the document remain
unchanged (if changed than in relation to some other CR).
This means:
- The lifetime of a timer is still related to the scope unit in which it
is declared.
- For example, if a local timer is declared and started in a function
(or altstep) and the function (or altstep) ends, then the timer is
destoyed like any other local variable.
- I hope this explains why the timer lists in the operational semantics
are still handled similar to variables (i.e., a list of lists of timer
states and each list in the list of lists refers to a scope in a call
hierarchy).
Now to the changes:
- If a function A with local variables and timers calls another function
B, the local definitions of A are not visible in B (I assume here that
the local definitions are not passed into B as parameter).
- This means that the local variables and timers defined in A cannot be
accessed "directly" in B because they are not known (you cannot start a
timer which you do not know).
- The usage of ANY and ALL for timers was before the implementation of
CR 2151 also related to the actual scope in which ANY and ALL are used,
i.e., ANY/ALL timer/s in the actual scope unit.
- However, most TTCN-3 users and TTCN-3 tool vendors (please don't
comment "most" in possible follow-up mails) felt that timers are a
special species and that ANY/ALL for timer operations should not be
related to timers in the actual scope unit only, but also to timers in
scope units previously entered but not be left, e.g., in the example
above, if ANY/ALL is used in function B, it allows to check the status
timers declared in function B (of course, local scope) AND function A
(and possibly further timers in a deeper function call hierarchy).
- In the operational semantics this means that if ANY/ALL are used, we
have to iterate through all lists (existing scopes) in the list of lists
of timer bindings.
I hope this explains the changes in the core language document and how
this is reflected in the operational semantics.
Best regards
Jens
Michael Sperber schrieb:
> I'm trying to understand the semantics of timers, and the changes
> following the discussion in March. I'm afraid even after reading most
> of it I'm thoroughly confused, so I hope you'll indulge me if the
> questions I'm asking are stupid or have been answered before: your help
> would be much appreciated.
>
> First off, the 3.3.8 draft of the standard has reworded the text related
> to "all timer" and "any timer" to not mention scope any more. Clause
> 23.1 says that a running-timers list and a timeout-list are maintained
> at the component level. The mention of "scope" has been removed from
> the wording describing the handling of those lists. However, clause
> 23.2 starts off by saying "[...] to the list of running timers (for the
> given scope unit)." So what's the relationship between these lists and
> scopes? Specifically, are, say, running timers removed from the
> running-timers lists when they go out of scope?
>
> Also, it seems that the operational semantics have also been changed,
> but I don't understand the relationship between part 1 and part 4.
> Specifically, the running-timers list and timeout-list don't show up in
> the component state. The specification of the timeout operation still
> (as in v3.2.1) iterates over the timers according to the dynamic scope
> units, which appears to say at "any" and "all" *are* sensitive to the
> dynamic scope. (In clause 9.52 in part 4 (v3.3.8 again), there are two
> flow graphs for the stop operation that differ in this regard: I think
> one of them is simply the old one.)
>
> Moreover, I don't quite understand how snapshotting works with respect
> to timers. If the program calls an altstep, and that altstep declares a
> local timer instance, what are the semantics of the various operations
> looking at the timer snapshot? The local timer didn't exist when the
> snapshot was taken, so it didn't get included in the snapshot, right?
> If that's true, what exactly can the altstep do with the local timer?
> Same for function-local timers, I guess. (I'm sure I'm missing
> something obvious here.)
>
--
======================================================================
Prof. Dr. Jens Grabowski
Institute for Computer Science phone: +49 551 39 172022
University of Goettingen fax: +49 551 39 14415
Goldschmidtstraße 7
DE-37077 Goettingen
This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany)
www.swe.informatik.uni-goettingen.de
======================================================================
