Paul Eggert <[email protected]> writes: > This variable is 'long', not 'int'. > > 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. > > 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.
I'm not sure you can rely on the volatile bool write sequencing with a
read of a long.
I don't see the point of avoiding atomics here. It is a cheap and
simple case of it: a single relaxed load and single relaxed store should
cover it just fine:
static _Atomic (long int) sysconf_symloop_max_memo;
long int sysconf_symloop_max = (atomic_load_explicit
(&sysconf_symloop_max_memo,
memory_order_relaxed));
if (sysconf_symloop_max == 0)
atomic_store_explicit (&sysconf_symloop_max_memo,
sysconf_symloop_max = __sysconf (_SC_SYMLOOP_MAX),
memory_order_relaxed);
... or such (untested, not even compiled).
--
Arsen Arsenović
signature.asc
Description: PGP signature
