Re: visibility maps

"Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> writes:
> On Thu, Dec 11, 2008 at 5:01 PM, Zdenek Kotala <Zdenek(dot)Kotala(at)sun(dot)com> wrote:
>> IIRC, Memory reading/writing is atomic operation. Only one CPU(hw thread)
>> can access to the same memory address(es)* in same time*. The question is
>> how compiler compile C code to assembler. But this code seems to me safe.

> Yeah, I think the code is safe because we are just reading a bit.

There's no such thing as "just reading a bit" from shared memory.
Yes, you will get *some* value, but it is not very clear which value.

In particular, on machines with weak memory ordering guarantees
(PPC for instance), we put memory fence instructions into the
lock/unlock sequences to ensure that someone who obtains a lock
guarding a shared-memory data structure will see any changes made
by the previous holder of the lock. An access that is entirely
free of any locking primitive might get a stale value --- meaning
that it might be logically inconsistent with the apparent contents
of other parts of shared memory examined just before or after this
access.

It's likely that there are other lock/unlock operations somewhere in the
code that would prevent a visible failure; and in any case the usage of
the visibility map is constrained in a way that means getting a slightly
stale value isn't a problem. But it needs a lot closer analysis than
the existing code comment suggests.

I've been thinking for awhile that maybe we should expose the memory
fence operations as separate primitives, similar to what's done inside
the Linux kernel. This code would feel a lot safer if it had a read
fence just before the fetch. IIRC there are some other places where
we could use something similar instead of needing a full lock
acquisition/release.

regards, tom lane