This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: SUSv3's "memory location" and threads
- From: Brian Dessent <brian at dessent dot net>
- To: Adam Olsen <rhamph at gmail dot com>
- Cc: gcc-help at gcc dot gnu dot org
- Date: Mon, 27 Aug 2007 22:52:42 -0700
- Subject: Re: SUSv3's "memory location" and threads
- References: <aac2c7cb0708272219i2ce775c4r460970da2717f9b5@mail.gmail.com>
- Reply-to: gcc-help at gcc dot gnu dot org
Adam Olsen wrote:
> 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.
You can use a zero-length bitfield to indicate that two struct members
are not to be coalesced: "struct { char foo; int : 0; char bar[3]; }".
Now I'm not sure this would actually fix whatever problem you're
encountering (and if it did, it would probably be by happenstance, not
guarantee); and I'm fairly sure this is a nonstandard extension so it
might not be very portable, so caveat emptor.
Brian