Re: memcmp-sse4.S EqualHappy bug

[Torvald Riegel <triegel at redhat dot com>]

On Wed, 2015-06-17 at 23:06 +0200, Andrea Arcangeli wrote:
> On Wed, Jun 17, 2015 at 08:59:52PM +0200, Szabolcs Nagy wrote:
> > c11 has threads and a memory model that makes concurrency issues
> > observable in standard c.
> > 
> > however you have a data race that is undefined behaviour:
> > 
> > objects passed to memcmp are not supposed to be modified concurrently
> > without synchronization.
> 
> All right, I expected this was not a bug by the standard.
> 
> In my initial test code I had a contended pthread mutex at the start
> of the page that was passed to memcmp, I wasn't flipping bits myself,
> but I guess that's still undefined behavior if it's
> pthread_mutex_lock/unlock that are changing the memory passed to memcmp.

Yes, it is.

You also need to consider what you are telling the compiler by using
non-atomic (or non-synchronizing) accesses on a piece of memory.  If you
do that, you promise that there's no concurrent modification, which can
allow the compiler to optimize based on prior knowledge about the
memory's content.  Allowing such optimizations is important for generic
code, for example (ie, that one can write code written for the general
case and still expect the compiler to optimize for the specific case).
(That may not be the case in your specific case, but it's often
overlooked, and it is one reason why UB is "global" as Rich points out.)

Nonetheless, at least the C++ committee is working on specifying a means
to access non-atomic-typed data atomically (but requiring all concurrent
accesses to also be atomic then (e.g., by using the same means)).