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
"Adam Olsen" <rhamph@gmail.com> writes:
> On 27 Aug 2007 23:52:08 -0700, Ian Lance Taylor <iant@google.com> wrote:
> > "Adam Olsen" <rhamph@gmail.com> writes:
> >
> > > 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.
> >
> > Unfortunately there is no such way. The only way you could be sure in
> > a portable manner is for the C and/or C++ language standard to define
> > how multi-threaded code should behave. But they don't.
> >
> > The next C++ standard, C++0x is intended to include definitions for
> > multi-threaded programs. But it does not exist yet.
>
> I'm not concerned about C/C++ themselves, but rather how SUSv3 is
> interpreted. Even then I already know they don't actually specify
> these details, so I'm looking for a de facto interpretation.
>
> If everybody (threaded application developers, kernel developers, *gcc
> developers*) decide they'll use int's size and alignment, then it
> might as well be written in stone.
Modern processors really deal in cache line sizes when accessing
memory. The processors provide specific locking and/or cache control
instructions to deal with this, and mutex implementations use them.
There is ongoing work and research about how to best implement
multi-threaded memory access. I don't think it is yet possible to
write anything in stone about this.
Ian