On Fri, Oct 26, 2007 at 01:42:37AM +0200, Andi Kleen wrote:While this is OK in mono-threaded code, it introduces a race condition in multi-threaded code. The code above tried to acquire a lock, and eax was set to 1 if it succeeded. And whatever the result, all threads still happily modify the shared memory area (acquires_count). So the classical case where two threads perform the same operation at the same time ends up with a random value in acquires_count. Even with a CMOV, it's the memory write which should not be performed if the lock was not acquired. (...) 100% agree. What would really be needed is an attribute around conditions to indicate whether they *may* be optimized or not. Something similar to the likely/unlikely we currently use, we could have something like __attribute__((unsafe_cond(cond))). I think that it could still optimize by default but let the user explicitly state that he is playing with thread-unsafe code. As you pointed out, you did not find any such mis-optimization in the kernel, which means that it does not hit too often. That's the reason why I'd let the user be careful. Willy -
| Stephane Jourdois | Re: 2.6.21-rc4-mm1 [PATCH] init/missing_syscalls.h fix |
| David Brown | Re: Linux 2.6.21-rc2 |
| Andi Kleen | [PATCH] [1/12] x86: Work around mmio config space quirk on AMD Fam10h |
| david | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| David Miller | Re: [GIT]: Networking |
| David Woodhouse | Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
git: | |
