"Adam Olsen" <rhamph@xxxxxxxxx> writes: > On 27 Aug 2007 23:52:08 -0700, Ian Lance Taylor <iant@xxxxxxxxxx> wrote: > > "Adam Olsen" <rhamph@xxxxxxxxx> 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
