Re: Performance monitor signal handler

At 16:55 15/03/01 -0800, Alfred Perlstein wrote:
>* Philip Warner <pjw(at)rhyme(dot)com(dot)au> [010315 16:46] wrote:
>> At 16:17 15/03/01 -0800, Alfred Perlstein wrote:
>> >
>> >Lost data is probably better than incorrect data. Either use locks
>> >or a copying mechanism. People will depend on the data returned
>> >making sense.
>> >
>>
>> But with per-backend data, there is only ever *one* writer to a given set
>> of counters. Everyone else is a reader.
>
>This doesn't prevent a reader from getting an inconsistant view.
>
>Think about a 64bit counter on a 32bit machine. If you charged per
>megabyte, wouldn't it upset you to have a small chance of loosing
>4 billion units of sale?
>
>(ie, doing a read after an addition that wraps the low 32 bits
>but before the carry is done to the top most signifigant 32bits?)

I assume this means we can not rely on the existence of any kind of
interlocked add on 64 bit machines?

>Ok, what what if everything can be read atomically by itself?
>
>You're still busted the minute you need to export any sort of
>compound stat.

Which is why the backends should not do anything other than maintain the
raw data. If there is atomic data than can cause inconsistency, then a
dropped UDP packet will do the same.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/