What is the correct behaviour for timeout?

[cmnrd]

I am unsure about what the correct behaviour for the timeout target property is (See #725 for some context). The more I think about it the more I am wondering if the current specification makes sense.

The hanbook says:

The target property timeout specifies the last logical time at which reactions should be triggered. The last invocation of reactions will be at tag (timeout, 0).

Apparently, the C target implements this such that shutdown is triggered at (timeout, 0) (correct?). Are all other events with (timeout, 0) also triggered and reactions invoked for this tag? The C++ runtime implements this differently and there is a discrepancy between behaviours. In C++, the C++ runtime currently executes all reactions at tag (timeout, 0) and then triggers shutdown in the next microstep (timeout, 1)

In this context, I am questioning what the right behaviour should be. If request_stop() triggers shutdown at the next microstep, shouldn't also timout trigger shutdown one microstep earlier? Also, why do we execute all reactions at (timeout, 0), but not at (timeout, N) (with N>0)?

Also I am wondering what the meaning of a timeout of 0 should be. Apparently, in C, this immediately stops the execution. But is this a reasonable behaviour? In C++, timeout=0 simply means there is no timeout and the program runs forever. To me this seems very intuitive, but again there is a discrepancy between targets and we might want to unify this.

So, what are your thoughts?

[lhstrh]

Apparently, the C target implements this such that shutdown is triggered at (timeout, 0) (correct?). Are all other events with (timeout, 0) also triggered and reactions invoked for this tag?

I believe the answer to both of these is "yes." There is an interesting (awkward) corner case if there are any startup reactions that are defined after shutdown reactions (in the same reactor).

The C++ runtime implements this differently and there is a discrepancy between behaviours. In C++, the C++ runtime currently executes all reactions at tag (timeout, 0) and then triggers shutdown in the next microstep (timeout, 1)

One way to explain this behavior is the following slightly modified version of the text in the handbook:

The target property timeout specifies the last logical time at which a program stop is requested, meaning the last invocation of reactions will be at tag (timeout, 1).

In this context, I am questioning what the right behaviour should be. If request_stop() triggers shutdown at the next microstep, shouldn't also timout trigger shutdown one microstep earlier?

Sorry, I didn't understand this question.

Also, why do we execute all reactions at (timeout, 0), but not at (timeout, N) (with N>0)?

If we were to, there are plausible scenarios in which execution would continue on for an arbitrary number of iterations in superdense time, rendering the semantics of timeout a lot less useful, IMO.

Also I am wondering what the meaning of a timeout of 0 should be.

I think the idea was that startup and shutdown would be present logically simultaneous in this case. While this makes sense, this opens up the possibility of the corner case I described above, where a reaction triggered by startup executes after one triggered by shutdown, which might be weird.

Apparently, in C, this immediately stops the execution. But is this a reasonable behaviour?

I think it is. It basically specifies to allow reactions for a single tag only.

In C++, timeout=0 simply means there is no timeout and the program runs forever.

That doesn't seem useful to me, as the same can be achieved by not specifying a timeout at all.

[Soroosh129]

There is also a federated aspect to this. request_stop in federated execution might take time to propagate over the network, causing the actual stop tag to be much later than the tag at which request_stop is called. Timeout is something that all federates agree on from the beginning. I think it would probably be almost impossible to implement timeout using request_stop in federated execution in a way that it can always honor the indicated timeout by the user.

Also, having a dedicated top-level reactor for timeout would be slightly strange in federated execution because the timeout reactor will become its own federate.

[lhstrh]

I just wanted to point out that the alternative semantics sketched above do not hinge on using the API function request_stop to implement it, even though that might have been suggested by the wording. I agree that using request_stop in a federated setting would be a poor choice for coordinating shutdown at a well-known predefined tag.

[cmnrd]

As Marten pointed out, I was not proposing to modify the implementation of timeout such that we use request_stop internally. This discussion should be more about the specification of timeout. How this spec is implemented can of course differ between targets (and whether federated execution is used).

In this context, I am questioning what the right behaviour should be. If request_stop() triggers shutdown at the next microstep, shouldn't also timout trigger shutdown one microstep earlier?

Sorry, I didn't understand this question.

I meant later, not earlier ;). The behaviour of request_stop is to finish the current tag and to invoke shutdown reactions at the next tag (one microstep later). Intuitively I would assume that timeout has the same behaviour: finish processing the tag at (timeout, 0) and then invoke shutdown. I find it surprising that apparently timeout and request_shutdown have different semantics.

In C++, timeout=0 simply means there is no timeout and the program runs forever.

That doesn't seem useful to me, as the same can be achieved by not specifying a timeout at all.

This is true if you only consider the timeout property. But in C++ we also have the CLI option (I believe in C as well?) that allows to overwrite the timeout. But how do you switch off the timeout from the CLI for a program that has the timeout property set? I find --timeout 0 very useful (and intuitive) for that.

[edwardalee]

On the usefulness of the command line option --timeout 0, I think that in C, this should be --timeout FOREVER, which strikes me as far more intuitive than --timeout 0.

[soroush]

I'm with @soroush on this one.

Thanks for your support!

I believe a 0 timeout virtually means a blocking call. For all intents and purposes, it should be treated as such. That is consistent with most concurrency APIs such as the one in std::timed_mutex or even pthread_mutex_timedlock. 🤔

[lhstrh]

I believe a 0 timeout virtually means a blocking call.

I don't understand what you mean by this...

[Soroosh129]

I'm with @soroush on this one.

Thanks for your support!

I believe a 0 timeout virtually means a blocking call. For all intents and purposes, it should be treated as such. That is consistent with most concurrency APIs such as the one in std::timed_mutex or even pthread_mutex_timedlock. 🤔

Well, I think there’s been a mixup in GitHub tags :)

I’m not sure if a blocking call would be the right analogy to use for timeout in Lingua Franca.

[lhstrh]

Oh, 🤦 hi @soroush...

@edwardalee it's @Soroosh129 not @soroush 😆

[lhstrh]

I'd also like to suggest that we can easily detect the corner case that I described: if timeout is set to zero and there are shutdown reactions defined before startup reactions, we can issue a warning. We currently don't do this, but perhaps we should.