Should register_timer be lock protected?

[KammutierSpule]

I understand the need for lock/unlock of active_list. I understand the not need for protection on timer_array generally, except on: register_timer, unregister_timer and also on clear() functions.

These functions could be accesses by multiple tasks which can lead to corruption of timer_array.

Or did I miss interpreted something?

[jwellbelove]

I was working on the assumption that these would be called at the initial setup. There seemed to be no real need to dynamically register or unregister timers.

[KammutierSpule]

"these would be called at the initial setup" ok, would be possible, but it is something to be aware while using this library, which lead to extra awareness need.

I didn't check yet my application when I register the timers, I will back to this later.. but would be helpful to add this concern to the documentation.

[KammutierSpule]

I was working on the assumption that these would be called at the initial setup. There seemed to be no real need to dynamically register or unregister timers.

I was evaluating a bit more this, the way I was thinking to use timers may be a more "timed general propose trigger of events and run of simple tasks" so it could run very small code (kind of lambdas).

This way, I'm seeing that on a relative medium complexity application, the limit of about 254 timers could easily be reached.

Use case: I may only need on a specific sporadic state to use a timer and then don't need any more. (so why keep the handler?) Use case: There may be one task that will use frequently one or other timer, but will need more single shot timers. So should I allocate (register) all timers initial? even if I don't use it most of them all the time?

Does it sounds to be an improvement for etl::timers or should I wrap and implement something on top of etl::timers?

[KammutierSpule]

Use case: There may be one task that will use frequently one or other timer, but will need more single shot timers. So should I allocate (register) all timers initial? even if I don't use it most of them all the time?

with current etl::timer, I may externally and initially register all the expected timers the task will use and pass it "here is your array of timer IDs", but later I would need also to expose the timer class controller (which I can't protect the task to make the mistake to register/unregister more timers)