[riot-notifications] [RIOT-OS/RIOT] sys: single interrupt handler thread for interrupts in modules with blocking functions (#10555)

Gunar Schorcht notifications at github.com
Sun Jul 28 10:23:30 CEST 2019

@maribu I'm still not really convinced to ignore priorities completely (sensor IRQs versus GPIO IRQs).

> 2. A priority queue only solves partly the problem. In case a slow operation is already in progress, a high priority IRQ might still be acted upon to late.

Yes. It wouldn't be a good idea to preempt an ongoing I2C bus access at all. 

But, shouldn't we at least try to avoid that low priority ISRs block high priority ISRs if possible, that is, before they are executed? Prioritization with `event_queue` would require to have one thread for each priority. So even if we would say that we know only high and low priorities, two threads were necessary.

>> I can change it to use the `event_queue` instead of the `priority_queue`.

> This would solve the issue at hand with the least amount of added complexity.

I still don't understand why the complexity increases by using `priority_queue` instead of `event_queue`. Sure, the complexity of `priority_queue` is higher than the `event_queue`. But this is only the case, if there are more than one elements in it. And even if there would be two or three elements in the queue, would this really be an issue? How often does this happen?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190728/858cd09a/attachment.htm>

More information about the notifications mailing list