Neil Conway wrote: > Magnus Hagander wrote: >> Ok. But it should be safe if it's int32? >> > You should probably use sig_atomic_t, to be safe. Although I believe > that read/writes to "int" are atomic on most platforms, in any case.
Ok. That's an easy enough change. >> Actually, since it's just statistics data, it wouldn't be a problem that >> it's not atomic, I think. If we really unlucky, we'll get the wrong >> value once. >> > I don't think that's the right attitude to take, at all. Why not just > use a lock? It's not like the overhead will be noticeable. Probably, but none of the other code appears to take a lock out on it :) > Alternatively, you can get a consistent read from an int64 variable > using a sig_atomic_t counter, with a little thought. Off the top of my > head, something like the following should work: have the writer > increment the sig_atomic_t counter, adjust the int64 stats value, and > then increment the sig_atomic_t again. Have the reader save a local copy > of the sig_atomic_t counter aside, then read from the int64 counter, and > then recheck the sig_atomic_t counter. Repeat until the local pre-read > and post-read snapshots of the sig_atomic_t counter are identical. Thinking more about it, I think that's unnecessary. 32 bits is quite enough - if you're graphing it (for example), those tools deal with wraps already. They're usually mdae to deal with things like number of bytes on a router interface, which is certainly > 32 bit a lot faster than us. But I'll take note of that for some time when I actually *need* a 64-bit value.- //Magnus ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster