Enhance the auto event execution

[cloudxxx8]

🚀 Feature Request

Relevant Package [REQUIRED]

This feature request is for device sdk

Description [REQUIRED]

The current issue is described here: https://github.com/orgs/edgexfoundry/discussions/310#discussion-7202203

Describe the solution you'd like

wrapping the execution (read + send event) as an asynchornous function

[cloudxxx8]

Discussed this issue in the Technical Working Group meeting on 24-Sep-2024, this issue will cause the original behavior change, so we won't implement it in v3 to prevent any breaking change.
@eaton-coreymutter please help provide your suggestion in this issue, thanks.

[eaton-coreymutter]

Currently the autoevent executor loop is, in simplified pseudocode:

• sleep for the autoevent duration
• call the service's read function
• send the resulting event, on a background thread

and if the "call the service's read function" takes noticeable time relative to the autoevent duration we get the skew described in the issue.

My suggestion:

• deadline = now + autoevent-duration
• call the service's read function
• send the resulting event, on a background thread
• if now < deadline, sleep for (deadline - now) duration

This way, if the service's read function is fast, this behaves like today. If the read function takes noticeable time, the autoevents will not skew, they will happen at the given interval. If the read function takes longer than the autoevent interval, events will come at the speed of the read function, slower than the autoevent interval but without "piling up" requests.

[syoliver]

@eaton-coreymutter

I think the proposal is interesting. However, in the first step of your suggestion

deadline = now + autoevent-duration

you take the time immediately after calling time.After. The time elapsed between the expected wake-up time of time.After and the result of Now() is not negligible. At the end of the day, as this time accumulates, the time lag can add up to minutes. It is worse when the device running the device service has few cores that are running many go routines/threads in many processes (maybe isolated in many docker containers).

As a result, I propose

deadline = deadline + autoevent-duration

On the other hand, in doing so, it is necessary to deal with cases where a read takes longer than the autoevent-duration. It can be explicitly discarded without informing anyone except writing a warning log. Or an event can be sent to keep track on the canceled reads somewhere.

And there's another subject that, although not quite the same, is closely related. Having one go routine per executor prevents reads from being synchronized with each other. Rather than grouping read commands, they are executed concurrently. And in some device services, they may interlock. It would be more efficient to synchronize the deadlines of each autoevent and group the reads as much as possible. This would give the device service more flexibility to optimize its requests, with less risk of interlocking and a better chance of responding within the autoevent-duration whatever it may be.
It can be achieved by removing the "one go routine by executor" behavior and synchronizing all auto events deadlines.