Re: SUSv3's "memory location" and threads

[Ian Lance Taylor <iant at google dot com>]

Darryl Miles <darryl-mailinglists@netbauds.net> writes:

> Ian Lance Taylor wrote:
> > "Adam Olsen" <rhamph@gmail.com> writes:
> >
> >> For example, if I had "struct { char foo; char bar[3]; }", where my
> >> first thread had a pointer to foo and was modifying it, while my
> >> second thread had a pointer to bar and was modifying it, would that
> >> meet the requirements?  My understanding is that a C compiler can (and
> >> in many cases, will) use larger writes so long as they appear the same
> >> for a single-threaded program; this obviously breaks threading though.
> > Yes, that can happen.
> 
> Can you cite an example with GCC on a given CPU or do you mean because
> the C specification doesn't rule it out then it is possible for some
> compiler somewhere to use this method of access.  So in a purity sense
> "it can happen" but in reality an example maybe difficult to find.
> 
> Byte accesses are usually done with byte sized load and store
> instructions.  It would seemly require more instructions and more work
> to load / shift / mask / store using larger width load/stores than was
> necessary.

I guess the most relevant question is: when would gcc ever use a
read-modify-write sequence to implement a simple assignment to part of
a struct.  You're probably right: gcc will probably never do that if
byte-wite memory access instructions are available.  Some processors
of course do not have such instructions, in which case gcc must always
use a read-modify-write sequence for assignments to byte fields.

gcc will combine multiple assignments to struct fields into single
assignments (e.g., combine an assignment to two 8-bit fields into a
single 16-bit write), but that isn't going to cause the error case
which matters here.

Ian