4

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.

peterh
  • 11,875
  • 18
  • 85
  • 108
  • 2
    The "duplicate" doesn't answer my question, it is a completely different question. – peterh Sep 02 '15 at 09:30
  • 2
    It's the exact same question if you look at its body and not only the title. – interjay Sep 02 '15 at 09:33
  • @interjay It only doesn't answer the essence: if I can use std::atomic to handle reentrancy in signal handlers. – peterh Sep 02 '15 at 09:36
  • 3
    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? – Klaus Sep 02 '15 at 09:38
  • @Klaus Since your comment, no. :-) – peterh Sep 02 '15 at 09:40
  • Klaus' comment answered finally my question. – peterh Sep 02 '15 at 09:41
  • @interjay 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. – peterh Sep 02 '15 at 09:44
  • I agree with interjay. As the "marked as duplicate" box explains, the SO criterium is that "the question already has an answer". – MSalters Sep 02 '15 at 10:02
  • @MSalters 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. – peterh Sep 02 '15 at 10:42

1 Answers1

7

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).

Tony Delroy
  • 102,968
  • 15
  • 177
  • 252
  • 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`. 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? – Ben Apr 25 '18 at 12:53
  • 1
    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 https://community.arm.com. I'm afraid I've never programmed ARM assembler, nor even deployed C++ on ARM. Best of luck. – Tony Delroy Apr 26 '18 at 12:34