Hi Michael,
well, that is not my field of expertise ... triTimeout is called by the
PA in the TE ... as this call may occur at any time, a separate thread
seems to be a logical choice ... however, TRI does not prescribe how you
implement.
Cheers, Ina
Prof. Dr.-Ing. Ina Schieferdecker, Head of Competence Center
Modeling and Testing url:
www.fokus.fraunhofer.de/go/motion
Fraunhofer FOKUS email:
This email address is being protected from spambots. You need JavaScript enabled to view it.
Kaiserin-Augusta-Allee 31 tel: ++49-30-3463-7241
D-10589 Berlin fax: ++49-30-3463-8241
>
Original Message
> From: active_ttcn3 : mts stf133 ttcn version 3 - active
> members only [
This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Michael Sperber
> Sent: Monday, May 11, 2009 8:10 AM
> To:
This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: triTimeout issues
>
> The specification of triTimeout says nothing about the
> context in which
> the timeout runs: Is anything known about that context? Specifically,
> it appears as though triTimout may or may not run in a separate thread
> from the TE (on platforms that support it). If this is true, it
> complicates implementation significantly:
>
> - If triTimeout runs in a thread separate from the TE, it needs to
> synchronize on data structures shared with the TE.
>
> - If it does not run in a separate thread, it still needs to
> synchronize
> on shared data structures, but this would seem to require starting a
> new thread from within triTimeout to handle the timeout.
>
> Is this analysis correct? I'd be grateful for clarification.
>
> --
> Regards,
> Mike
>
