Is std::atomic signal-safe? [duplicate]

Question

I am working on a Linux app, which needs to be able to handle large bursts of signals. Although the signal handlers will run fast (I plan at most some thousands of cpu cycles), the signals will come in big bursts, and ideally I would completely disable signal masking (even not themselfes, see SA_NODEFER in sigaction).

Thus, I need to implement the signal handlers on a completely reentrant way. I think std::atomic would be an useful thing for the task, but I think, std::atomic was developed to handle thread-based race conditions, and not necessarily race problems coming from stacked on signal handlers.

Phaeton

The "duplicate" doesn't answer my question, it is a completely different question. – Phaeton

It's the exact same question if you look at its body and not only the title. – Phantom

@Phantom It only doesn't answer the essence: if I can use std::atomic to handle reentrancy in signal handlers. – Phaeton

The answer to your question is already given: If your atomic is lock free, you can use it. If it is not, use a sig_atomic_t. I am wrong? – Mammalian

@Mammalian Since your comment, no. :-) – Phaeton

Klaus' comment answered finally my question. – Phaeton

@Phantom I would suggest to wait next time a little bit, or at least mark as "possibly duplicate" instead of a close on the spot. Single-person decisions mean greater power, but also mean greater responsibility. – Phaeton

I agree with interjay. As the "marked as duplicate" box explains, the SO criterium is that "the question already has an answer". – Rooker

@Rooker On my opinion, the answer is in Klaus' comment, and not in the refered question. Although the refered question may help to dig out the needed info with a little bit of googling, the answer which Klaus gave, isn't there. – Phaeton

Answer 1

If is_lock_free is true then you're ok, otherwise you could deadlock if the same atomic variable is accessed in the main thread and a signal handler, or in a lower and higher priority signal handler: remember they all share a stack and there's no way for the running handler to let code it's interrupted continue for long enough to unlock a resource (without simply returning and not doing its own work).

Lousewort

I’m wanting to write an interrupt-safe ring buffer for ARM Cortex-M0+ With one reading interrupt and one writing (so no contention for the same variable). The end “pointers” are uint8 indices into the buffer. My reading of the processor docs is that a writing a byte should(?) be atomic. Yet is_always_lock_free is false for my std::atomic<uint8_t>. Since I don’t need compare-and-swap, I just need release/acquire, and my data structure is statically allocated, it looks like the assembly it produces a correct. Do I have any static guarantees? Why would is_always_lock_free be false? – Duma

Hi @Ben. It would be better to post a new question so you get the attention of people with ARM knowledge. You could also consider asking at community.arm.com. I'm afraid I've never programmed ARM assembler, nor even deployed C++ on ARM. Best of luck. – Lousewort