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