Paul Eggert wrote: > > Storing the same value in the same location (of > > type 'int') is OK not only on those platforms where an 'int' access is > > atomic, > > but even on architectures (such as m68k) where it isn't. > > This variable is 'long', not 'int'.
Oops, right. But anyway, 'long' is the size of a machine word, and except on m68k, for aligned accesses, loads and stores of such words are atomic. > Come to think of it, though, on GNU/Hurd aren't we in a bit of trouble > here? One thread might be writing -1 while another is reading, and a > torn read might cause the latter to see "65535" instead of -1. Indeed, I was only thinking about write/write races, but there are also read/write races. The scenario you describe can only occur on Hurd/m68k, a platform that will never exist. > We needn't go to atomic accesses to fix this, I'd think, just to a > volatile bool saying whether the long int is initialized, along with > rejiggering the accesses to the long int. Yes, adding 'volatile' would be an optimization: it would reduce the probability that different threads execute the sysconf call again without necessity. Bruno
