runtime (scheduler): add revised arm scheduler with support for atsamd21 #1010
Conversation
This commit adds a queue wrapper type which can be used to transfer tasks between interrupts and the scheduler.
| // poll checks for any expired timers and schedules them. | ||
| // This must be called periodically by the scheduler. |
There was a problem hiding this comment.
This feels like a possible problem. Why is there a need for polling?
There was a problem hiding this comment.
We have 2 kinds of platforms in TinyGo:
- microcontrollers - where all events come from interrupts
- "hosted" platforms (wasm, embedded linux, etc.) - where we need to periodically poll for events
We could use 2 different scheduler implementations, one interrupt based and one polling, but that would make some stuff more complicated and result in 2 different sets of behavior.
There was a problem hiding this comment.
What kinds of events need to be polled for on hosted platforms? Epoll?
I may need to look more into it to understand the problem better.
|
I looked at the code, but I'm not fully grasping what it is doing. I looked at #1002 (which is pretty clear), this PR, and #1010 but I miss the big picture. Reading through the code I see a lot of newly added code and some changed code but somehow I'm missing the purpose. Questions I get are:
So can you maybe give a high level overview of what this particular PR is doing, why things are done the way they are, and what's up with all the polling? Also, how this will eventually result in things like interrupt-safe conditional variables? |
|
I'm a bit late here. But still. Is there a reason why you went for this almost entirely lock-free approach? I do not think it's a problem to disable interrupts for a short time when working with the runqueue. |
It is legacy. WebAssembly has somewhat different semantics - we never need to re-check the timer, and all of the time queueing can be done at the end.
Ticks was not moved. The code before it was deleted, and new code was put there, and git decided that was how it wanted the diff to appear.
On hosted systems, there is no way around polling. On microcontrollers, we need to copy awoken tasks to the runqueue (although we may want to look into more frequent polling there, since it is cheap).
I think the timer system still currently makes sense to leave separate, since we have to constantly reorder and reschedule things. The timer controller mechanism is designed to be a simplified version of working with interrupt timers, and is supposed to become the standard mechanism for implementing runtime timers. |
The interrupt-safe condition variables push awoken tasks onto the interrupt queue. This change feeds those tasks into the runqueue and lets them be resumed.
I guess we could do this. I was just worried that we could potentially be doing a lot of manipulations to the runqueue, and this would mean that a large total time would end up spent with interrupts off. If you want, I can redesign this a bit to instead disable interrupts. |
|
Closing in favor of #1142 |
2 participants
This PR is based off of #1006 and #1002. As of now, the queue is not yet exposed to anything. I will add that in a bit.