NetworkChannel Polling Abstraction

[tanneberger]

This discussion is motived by the requirements of the S4noc, which only provides the user with a status register to check whether data is available. The second problem is that the Patmos platform does not support multithreading. Therefore, we cannot simply spawn a new thread that loops and receives data.

The solution that seems most attractive to me at the moment is to rename our current NetworkInterface to AsyncNetworkInterface and create a new PollNetworkInterface that enforces a homegenous polling API.

typedef enum {
 NETWORK_INTERFACE_ASYNC,
 NETWORK_INTERFACE_POLL
} NetworkInterfaceType;

typedef struct {
 NetworkInterfaceType interface_type;

 // ...
} NetworkChannelInterface;

typedef struct {
 NetworkChannelInterface super;

 // ...
} AsyncNetworkChannelInterface;

typedef struct {
 NetworkChannelInterface super;

 bool (*data_available)(PollingNetworkChannelInterface* self);
 void (*poll)(PollingNetworkChannelInterface* self);

 // ...
} PollingNetworkChannelInterface;

The remaining unpleasant problem is that we still want to poll for new data while the runtime environment goes to sleep, but there are two sensible solutions in my opinion:

• 1. Schedule internal dummy events in a certain time period to keep the runtime busy and thus keep polling.
• 2. In the case of S4Noc, we could also consider changing the implementation of sleep function on the Patmos platform so that it either wakes up when time has elapsed or new data is available on the S4NocNetwork channel.

[erlingrj]

Hm, that is indeed unfortunate. We went back and forwards for a while before settling on the async, callback-oriented approach. I wonder if Patmos and S4NOC don't support interrupts? (@schoeberl ?).

[schoeberl]

Patmos does support interrupts. I just do not like them ;-)

You know devices can bring down systems when issuing to many interrupts. E.g., in the old days Windows was disabling interrupts when getting too many and switched to polling. On the other hand, interrupts can get lost, so devices started to reissue interrupts when not being served in time.

[erlingrj]

That is true. Well, we could require a parameter called something like polling_interval to be set for any PolledNetworkInterface. We could then either add some logic inside the runtime that, before going to sleep, checks if we have any PolledNetworkInterfaces and what is the minimum polling interval, and then limit the sleep durations to the polling_interval. Or, we could do it more at the LF-level and code-generate an "empty" timer. I.e. a timer without any effects. It would force the runtime to always advance time to the tags of the timer and would be like Tassilos "dummy event"

[schoeberl]

OK, great that we find a polling solution. We can later look into interrupts as well, but a software only solution is an easier step forward (instead of adding HW and introducing true concurrency). polling_interval is a good idea. At least it is a kind of contract what the runtime needs to do.