Decentralized federation silently delivers the wrong tag

[edwardalee]

In the following example, the Print reactor receives messages at microstep 1 that were sent at microstep 0. The issue is that unless there is an STP violation handler given (it's commented out below), STP violations appear to be silently ignored. Adding an STP handler to the first reaction of Print with offset 0 detects the error, but I think the error should be detected even without it. Otherwise, the program silently executes as if it were doing the right thing.

target C {
    timeout: 5 sec,
    coordination: decentralized
}
reactor Count {
    output out:int;
    state c:int(0);
    timer t(0, 1 sec);
    reaction(t) -> out {=
        lf_set(out, self->c++);
    =}
}
reactor Print {
    timer t(0, 500 msec);
    input in:int;
    reaction(in) {=
        lf_print("***** Received: %d at (%lld, %d)", in->value,
            lf_time_logical_elapsed(), lf_tag().microstep
        );
    // =} STP(0 msec) {=
    //    lf_print_warning("Safe to process violation!");
    =}
    reaction(t) {=
        lf_print("***** Timer ticked at %lld.", lf_time_logical_elapsed());
    =}
}
federated reactor {
    c = new Count();
    p = new Print();
    c.out -> p.in;
}

Running this program gives the following:

Federate 1: ***** Timer ticked at 0.
Federate 1: ***** Received: 0 at (0, 1)
Federate 1: ***** Timer ticked at 500000000.
Federate 1: ***** Timer ticked at 1000000000.
Federate 1: ***** Received: 1 at (1000000000, 1)
Federate 1: ***** Timer ticked at 1500000000.
Federate 1: ***** Timer ticked at 2000000000.
Federate 1: ***** Received: 2 at (2000000000, 1)
Federate 1: ***** Timer ticked at 2500000000.
Federate 1: ***** Timer ticked at 3000000000.
Federate 1: ***** Received: 3 at (3000000000, 1)
Federate 1: ***** Timer ticked at 3500000000.
Federate 1: ***** Timer ticked at 4000000000.
Federate 1: ***** Received: 4 at (4000000000, 1)
Federate 1: ***** Timer ticked at 4500000000.
Federate 1: ***** Timer ticked at 5000000000.
Federate 1: WARNING: Received message too late. Already at stopping time. Discarding message.

[Soroosh129]

but I think the error should be detected even without it.

But how would that work? Should the program exit or drop the message?

The error is being detected, but there is just no handler for it.

[edwardalee]

Good question. I'm not sure what we should do. Probably not exit. Dropping the message and printing a warning seems reasonable to me. The message should perhaps explain how to provide a handler...

[Soroosh129]

The way I see it is that logical connections under decentralized coordination provide best-effort alignment. In the case of the original example here, even with an STP offset, the input port might not always align with the timer. An STP violation is not necessarily an error if this best-effort alignment is all that is needed for an application. In other words, not having an STP violation handler could be a legitimate and deliberate design choice. Dropping messages thus can actually be potentially limiting and surprising.

Perhaps, as a compromise, we could issue a warning during code generation if there are no STP handlers for a logical connection under decentralized coordination.

[edwardalee]

I think the key is this principle: Any execution of an LF program is correct only if it matches LF semantics. Currently, that is not what happens, so this is an incorrect execution.

In the case that you don't want to drop the message, you can just provide an STP handler that also handles the message.

[Soroosh129]

Is it correct LF semantics if events simply disappear (in the case of dropping messages)?

[edwardalee]

You are right. Unfortunately, we don't have any consistent exception handling mechanism. Maybe we should think about introducing that. E.g., there would be an API to provide an exception handler function, and the default would be to print an error message and exit?

[Soroosh129]

there would be an API to provide an exception handler function, and the default would be to print an error message and exit?

I agree that this could be the optimal solution.

[lhstrh]

Should we add exception handling as a topic for the retreat?

[edwardalee]

Sure! Annotations too.