| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 24 Oct 2007 21:29:56 -0700 From: "David Schwartz" <davids@...master.com> To: "Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org> Subject: RE: Is gcc thread-unsafe? > Well that's exactly right. For threaded programs (and maybe even > real-world non-threaded ones in general), you don't want to be > even _reading_ global variables if you don't need to. Cache misses > and cacheline bouncing could easily cause performance to completely > tank in some cases while only gaining a cycle or two in > microbenchmarks for doing these funny x86 predication things. For some CPUs, replacing an conditional branch with a conditional move is a *huge* win because it cannot be mispredicted. In general, compilers should optimize for unshared data since that's much more common in typical code. Even for shared data, the usual case is that you are going to access the data few times, so pulling the cache line to the CPU is essentially free since it will happen eventually. Heuristics may show that the vast majority of such constructs write anyway. So the optimization may also be valid based on such heuristics. A better question is whether it's legal for a compiler that claims to support POSIX threads. I'm going to post on comp.programming.threads, where the threading experts hang out. A very interesting case to be sure. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists