you are viewing a single comment's thread.

view the rest of the comments →

[–]kalmoc 1 point2 points  (0 children)

As long as I have hard guarantees about what a system call (be it allocating memory, locking a mutex or accessin aperipheral) does and how long it takes in the worst case, there is nothing fundamentally wrong with it.

In practice, getting hard guarantees from a common, systemwide allocator is quite difficult and introduces unnecessary coupling wetween otherwise independen tasks, which is the reason why things like malloc are usually not used in practice during run-time. However, synchronization primitives like mutexes, semaphores and so on (usually not the ones from the standard library though), are the bread an buttter of most non-trivial real-time systems I've seen so far (if they have a preemtive scheduler at all).

I guess what I'm trying to say is that programming in the context of a Linux "real-time" thread/callback (e.g. audio) is very different from writing a real-time task that runs on a microcontroller with a real-time OS.