[HN Gopher] Moving CHERIoT RTOS to a tickless model
___________________________________________________________________
Moving CHERIoT RTOS to a tickless model
Author : JNRowe
Score : 46 points
Date : 2024-06-08 00:01 UTC (22 hours ago)
(HTM) web link (cheriot.org)
(TXT) w3m dump (cheriot.org)
| brcmthrowaway wrote:
| Is Linux/Windows/Mac tickless?
| lionkor wrote:
| Unsure if this is clear so I'll say it: Those are not real time
| OSs
| sertsa wrote:
| Pretty sure that most people here know that, so it remains a
| less obvious yet interesting question (while tangential to
| the posted article): Are Linux/Windows/Mac tickless?
| ninkendo wrote:
| I know Linux is, the rest probably are too. I remember when
| tickless support was merged:
|
| https://lwn.net/Articles/549580/
|
| https://lwn.net/Articles/659490/
| layla5alive wrote:
| It's easy to assume OS schedulers have a lot of intellect behind
| them, but in reality, like most software, they're often shipped
| in a half-baked state. Even mature schedulers like the Linux
| kernel are far from perfect.
|
| It surprised me that yield wasn't a concept from the beginning
| for this RTOS (reading it, when they started describing the
| problem, I was already asking "why aren't they yielding instead
| of sleeping?"), but glad to see the improvement in the next
| paragraph.
|
| There are always things to improve, which I find refreshing - I
| hope AI doesn't take that away. Or if it does, it had better also
| eliminate poverty, war, etc. Let people spend their days playing.
| klyrs wrote:
| No, people are using AI to do all the fun stuff like art,
| poetry, programming. Humans are great at cleaning the bits out
| of a meat grinder tho.
| 01HNNWZ0MV43FF wrote:
| Interesting. I don't know much about OSes, but in userspace
| there's an analog for event loops.
|
| Almost all of them have a timer heap or timer wheel or something
| (that's below the level of abstraction I work at) which can
| always answer the question, "When do I wake up next?". And then
| every event is reducible to either a timer timeout or an external
| event like the file driver giving you data from a file, getting a
| packet from the network, mouse movement, etc.
|
| Games often don't need this because they tick at 60+ Hz to render
| everything anyway, so it's easier to just hang everything off
| that and check every timer on every frame, it's going to be a
| tiny waste of CPU compared to the rest of the game logic.
|
| However in one case I was writing an event-based program for
| work, using C++, with limitations on what dependencies I could
| pull in, so I set a fixed tick (something like every 1 second)
| and when I got external events, I just ran the whole tick
| function instantly. This introduced some latency but it was in
| places that didn't matter, and it made the code really easy to
| follow.
| theamk wrote:
| > almost all of the calls to thread_sleep wanted to yield to
| allow another thread to make progress, rather than to guarantee
| some time had elapsed.
|
| That's .. deeply alarming and likely indicates the bad code. I've
| seen many beginner programmers use sleep/yield to busy-wait on
| something, and it's almost always a bad design decision: using
| proper synchronization primitive would be safer and more
| performant too.
|
| Just to make sure that my guess was correct, I've searched
| CHERIoT codebase for some thread_sleep calls. There were only 15
| hits, and most of them were related to implementation; only two
| examples were actual use in the code: busy-wait in TLS stack and
| polling for response in SNTP driver. Both of those are bad design
| - they should be using proper synchronization mechanisms.
___________________________________________________________________
(page generated 2024-06-08 23:01 UTC)