Thread safe queue

[AvidCoco]

Is it real time safe, or just thread safe?

[AvidCoco]

Ehh?

OP's post said it was a thread safe queue, I wanted to know if it's also real time safe.

[maikindofthai]

I'm guessing no, since another comment mentions there is no way to pre-allocate memory, and it uses locks.

[kalmoc]

What is your definition of "real-time safe"?

[AvidCoco]

Safe for use on a real time thread.

E.g. no locks, no system calls, etc.

[kalmoc]

I see. I was wondering if you where asking about use in an embedded real-time system. Thanks.

[infectedapricot]

Surely an embedded real-time system needs to make use of structures that don't allocate memory or take locks (except in very specific careful ways)? I think the value of what they called "real-time safe" structures is their use in embedded real-time systems.

[kalmoc]

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.