That's fine - if you have two threads modifying the same variable at the
same time, you need to lock it.
That's not the case under discussion.
The case under discussion is gcc writing back values to a variable that
NEVER HAD ANY VALIDITY, even in the single-threaded case. And it _is_
single-threaded at that point, you only have other users that test the
value, not change it.
That's not an optimization, that's just plain broken. It breaks even
user-level applications that use sigatomic_t.
And note how gcc doesn't actually do it. I'm not saying that gcc is broken
- I' saying that gcc is NOT broken, and we depend on it being not broken.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/