Thread: how to let my program responds to CTRL+C (linux machine)

The second part of the reason is that sigatomic_t is a type guaranteed to be accessible atomically. A 64-bit value on 32-bit x86, for example, is not; it takes two memory reads to get it, and a signal that modifies that value could be raised between the two instructions.

Originally Posted by CornedBee

The second part of the reason is that sigatomic_t is a type guaranteed to be accessible atomically. A 64-bit value on 32-bit x86, for example, is not; it takes two memory reads to get it, and a signal that modifies that value could be raised between the two instructions.

Sure, that is a good point. But bool, int or char should not be 64-bit on a 32-bit native machine (one would hope).

--
Mats

Originally Posted by pheres

char is defined as one byte, right? are there architectures which accesses bytes in a non-atomic manner?

also what should prevent me from accessing any type I like and take over the guarantee for atomic access myself (eg use a critical section)?

If you "know what you are doing", I'd say you can access any type you want. But with the caveat that SOME architectures may not allow you to do that atomically. sig_atomic_t is there to be guaranteed to be atomic in all aspects on the target system.

I'm not aware of any machine that do not allow atomic access to bytes, but I do know that mips doesn't have a 16-bit access, only 8 or 32, so 16-bit words DO get accessed non-atomically, because it's a 32-bit read, mask off the unwanted 16 bits into a temp register, modify the actual data in a register and then "assembly is reverse of disassembly" as they say in the Haynes manuals.

--
Mats

Alpha doesn't have atomic byte access. It's only one memory read, obviously, but the full sequence for a byte read is, "align pointer, load quadword, mask and shift to leave only the byte in".

Always? You shouldn't use it for thread synchronization, if that's what you mean.

Originally Posted by pheres

I meant if it is allowed to write a sig_atomic_t typed variable concurrently from user threads without putting a critical section around it?

No. Neither does it "work" to write sig_atomic_t types from multiple threads that all signal simultaneously without some sort of locking mechanism.

Obviously, if all you are doing is setting the value to a different constant value, then it's not a problem. If you are trying to keep an accurate count of something, or otherwise using it in a way where another thread accessing reading the value in the middle of an update would cause a problem, then you need something else. Many processors have "locked" operations of some sort, which are used for the primitives of IPC operations - these can be used if you need quick updates to variables in a threaded environment.

The only guarantee with sig_atomic_t is that it's possible to write the whole value as one operation.

--
Mats

Should be in signal.h, I would have thought.

--
Mats