Re: SUSv3's "memory location" and threads

["Adam Olsen" <rhamph at gmail dot com>]

On 27 Aug 2007 22:41:17 -0700, Ian Lance Taylor <iant@google.com> 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.
>
> > Is there a specific variable size or alignment at which I can be sure
> > (portably, etc) that there will be no larger writes, and that I can
> > use locks correctly?
>
> Well, volatile sig_atomic_t (sig_atomic_t is defined in <signal.h>) is
> guaranteed to be safe in this scenario.  The C and C++ standards do
> not provide any other guarantees, as they do not define thread
> support.
>
> That aside, if you use locks correctly, I believe you should be safe
> in practice if you stick to variables which match the register size of
> the processor, or variables which are not in structs.

Of course replacing every member of every struct in a program intended
to be threaded with volatile sig_atomic_t would be highly impractical.

I realize I'm "probably" safe if I ensure adjacent members are at
least as large as int (or long, or maybe long long, depending), but
I'm extremely mistrustful of C.  I'm hoping to find a way to be *sure*
I'm behaving in a correct, portable manor.

This is just a theoretical problem though.  I've not found something
to fail in the field because of it.  (Not like I'd be likely to
realize even if it was compiled "wrong".)

-- 
Adam Olsen, aka Rhamphoryncus