Re: Rethinking stats communication mechanisms

"Bort, Paul" <pbort@tmwsystems.com> writes:
>> Anyone know a variant of this that really works?

> Here's a theory: If the counter is bumped to an odd number before
> modification, and an even number after it's done, then the reader will
> know it needs to re-read if the counter is an odd number. 

Great minds think alike ;-) ... I just committed exactly that protocol.
I believe it is correct, because AFAICS there are only four possible
risk cases:

* reader's read starts before and ends after writer's update: reader
will certainly note a change in update counter.

* reader's read starts before and ends within writer's update: reader
will note a change in update counter.

* reader's read starts within and ends after writer's update: reader
will note a change in update counter.

* reader's read starts within and ends within writer's update: reader
will see update counter as odd.

Am I missing anything?

Note in particular that this protocol does not assume atomic update
of the counter, so we don't need to worry about whether int is
sig_atomic_t.  If any of the bytes change, we have what we need.
We could use a counter narrower than int, but then there's some tiny
risk that the counter could wrap all the way around while the reader
is blocked.
        regards, tom lane