linux-kernel - Re: Is gcc thread-unsafe?

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:  <874pgf1qih.fsf@willow.rfc1149.net>
Date:	Thu, 25 Oct 2007 11:40:22 +0200
From:	Samuel Tardieu <sam@...1149.net>
To:	linux-kernel@...r.kernel.org
Subject:  Re: Is gcc thread-unsafe?

>>>>> "Nick" == Nick Piggin <nickpiggin@...oo.com.au> writes:

Nick> Hi David, [BTW. can you retain cc lists, please?]

Nick> On Thursday 25 October 2007 14:29, David Schwartz wrote:
>> > 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.

Nick> A *conditional* store should no be a problem.

Nick> However the funny trick of doing this conditional add
Nick> (implemented with unconditional store), is what is going to
Nick> cause breakage.

Nick> On the CPUs where predicated instructions are a big win, I'd
Nick> expect they should also implement a conditional store for use
Nick> here. However they might be slower than an unconditional store
Nick> (eg. x86's cmov), and in those cases, gcc might just do the
Nick> non-conditional store.

>> 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.

Nick> This is not just a question of data that you were going to use
Nick> anyway.  gcc generates memory accesses to locations that would
Nick> never be accessed Even stores. It is basically impossible to say
Nick> that this is a real performance win. Even on single threaded
Nick> code: consider that cache misses take the vast majority of time
Nick> in many loads, which gives a little hint that maybe it's a bad
Nick> idea to do this ;)

>> Heuristics may show that the vast majority of such constructs write
>> anyway.  So the optimization may also be valid based on such
>> heuristics.

Nick> I'd never say the optimisation would always be useless. But it's
Nick> a nasty thing to have on by default, and apparently even with no
Nick> good way to supress it even if we want to.

>> 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.

Nick> Either way, I think we really need a way to turn it off for
Nick> Linux.

-- 
Samuel Tardieu -- sam@...1149.net -- http://www.rfc1149.net/

-
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/