3 ms·

Well, if you're programming bare metal you shouldn't be using any library's allocation routines but your own. Because, remember the cardinal rule: no mutices in

by webkike 10y ago

Well, if you're programming bare metal you shouldn't be using any library's allocation routines but your own. Because, remember the cardinal rule: no mutices in ISRs!

Taniwha 10y ago
I was kind of pointing out that people know that mutexes in ISRs are a bad idea, but don't know as much about the other dragons that live in the same swamp ... they may also simply not be aware of what's inside their libraries (which ones use mutexes? 'man printf' doesn't warn me) my point is that there are hidden mutexes in libraries that people often don't know about - his example of replacing new() with malloc() doesn't solve the problem, instead you need to be able to code your C++ without new, or at least the real-time bits of it (and that includes using stuff like strings and their libraries that do new() behind your back, or even printf which can run foul of the stdio hidden mutexes) It's not just ISRs, priority inversion is a real problem that results in some of the hardest bugs to find (I once had to chase one that happened only once a month, resulting in satellite systems losing their provisioning)
- erichocean 10y ago
  >I was kind of pointing out that people know that mutexes in ISRs are a bad idea, but don't know as much about the other dragons that live in the same swamp Honestly, these "people" seem like mythical creatures to me; I've certainly never met one. If you're qualified to write an ISR in C++, you're qualified to understand which parts of C++ are valid to use in an ISR and which aren't. This is a non-problem that does not appear in practice, even though it could in theory.
  - pjmlp 10y ago
    Somehow I can imagine that not being the case with offshored projects.
vardump 10y ago
No memory allocation in ISRs unless it's wait free, really fast and impossible to fail. Definitely no exceptions in ISRs. What would an exception really even mean in an ISR context? The "call" is done by the hardware, so there's no stack to unwind. Uncaught exception would practically mean system crash. Stack usage should be low, because ISR itself might get interrupted by a higher priority IRQ. ISR (interrupt service routine) needs to return as fast as possible, usually in a few microseconds. On x86, no FPU or SIMD in ISR either, unless you save and restore the registers. You need to cover all SIMD extensions, current and the future ones. If you use SSE but don't save AVX/AVX-512 registers, expect very weird bug reports. Better to simply avoid.
doomrobo 10y ago
Even avoiding mutices and using lock-free algorithms doesn't guarantee that your thread won't starve. As another comment mentioned, fast wait-free algorithms are what you need in this context.

by webkike 10y ago

Well, if you're programming bare metal you shouldn't be using any library's allocation routines but your own. Because, remember the cardinal rule: no mutices in ISRs!

Taniwha 10y ago

I was kind of pointing out that people know that mutexes in ISRs are a bad idea, but don't know as much about the other dragons that live in the same swamp ... they may also simply not be aware of what's inside their libraries (which ones use mutexes? 'man printf' doesn't warn me) my point is that there are hidden mutexes in libraries that people often don't know about - his example of replacing new() with malloc() doesn't solve the problem, instead you need to be able to code your C++ without new, or at least the real-time bits of it (and that includes using stuff like strings and their libraries that do new() behind your back, or even printf which can run foul of the stdio hidden mutexes) It's not just ISRs, priority inversion is a real problem that results in some of the hardest bugs to find (I once had to chase one that happened only once a month, resulting in satellite systems losing their provisioning)

erichocean 10y ago
>I was kind of pointing out that people know that mutexes in ISRs are a bad idea, but don't know as much about the other dragons that live in the same swamp Honestly, these "people" seem like mythical creatures to me; I've certainly never met one. If you're qualified to write an ISR in C++, you're qualified to understand which parts of C++ are valid to use in an ISR and which aren't. This is a non-problem that does not appear in practice, even though it could in theory.
- pjmlp 10y ago
  Somehow I can imagine that not being the case with offshored projects.

vardump 10y ago

No memory allocation in ISRs unless it's wait free, really fast and impossible to fail. Definitely no exceptions in ISRs. What would an exception really even mean in an ISR context? The "call" is done by the hardware, so there's no stack to unwind. Uncaught exception would practically mean system crash. Stack usage should be low, because ISR itself might get interrupted by a higher priority IRQ. ISR (interrupt service routine) needs to return as fast as possible, usually in a few microseconds. On x86, no FPU or SIMD in ISR either, unless you save and restore the registers. You need to cover all SIMD extensions, current and the future ones. If you use SSE but don't save AVX/AVX-512 registers, expect very weird bug reports. Better to simply avoid.

doomrobo 10y ago

Even avoiding mutices and using lock-free algorithms doesn't guarantee that your thread won't starve. As another comment mentioned, fast wait-free algorithms are what you need in this context.