Thread: sig_atomic_t to avoid mutex/critical sections?

If I use a sig_atomic_t x; data and with Linux pthreads I let them do only this:

(1)

Code:

x=value;

(2) or (separately)

Code:

if (x==value) {do something (not with x)}

(3) or (separately)

Code:

other variable (not shared) = x;

Can I be sure there is no race condition/unpredicted event/problem even if I do not use pthread_mutex_lock()/trylock()/unlock() to protect the shared sig_atomic_t x data?

In a few words: is it correct to speed up a software using sig_atomic_t data instead of mutexed data to prevent malfunctioning on shared data with the fundamental condition that data are as little as 2-4 bytes and are accessed only in the very simple way above?

sig_atomic_t doesn't really have anything to do with multi-threaded programming. The C standard says that any access to a global within a signal handler must be a write access and the type must be "volatile sig_atomic_t". The standard doesn't say much else on the subject.

As for POSIX, it's fairly clear on memory synchronization requirements in section 4.10: http://www.opengroup.org/onlinepubs/...html#tag_04_10

The only way you can be sure of anything is to follow POSIX memory synchronization requirements.

gg