On Thu, Oct 25, 2007 at 09:40:32PM -0700, David Miller wrote: > > Code like needs to use volatile or explicit memory barriers. > > I totally disagree with you, and I think POSIX does too.
Yeah. See also http://gcc.gnu.org/PR31862 Unsafe optimizations in loop IM, if conversion, etc. really either need to be conditionalized on some new switch whether code should be thread safe or not, or just need to be disabled altogether. Of course if gcc can prove the variable is written later on anyway before reaching any kind of barrier, it can do these optimizations anyway if it seems to be worthwhile. MEMs in current function's stack frame can be considered safe as well. > Threaded programming is hard enough as it is. > > What's the point of the lock if a test on whether we've obtained it or > not can't be used to conditionalize code execution? > > Any write to memory is a globally visible side effect, and even > ignoring theading issues I bet similar cases can be constructed > involving signals that behave equally unexpectedly and should not > require bogus memory barriers or volatile. > > I'm not sure people realize the true ramifications of this suggested > "fix". It is rediculious, by any measure. Jakub
