Re: visibility maps - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: visibility maps
Date
Msg-id 4940FA0F.50008@sun.com
Whole thread Raw
In response to Re: visibility maps  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: visibility maps  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
List pgsql-hackers
Heikki Linnakangas napsal(a):
> Pavan Deolasee wrote:
>>     /*
>>      * We don't need to lock the page, as we're only looking at a single
>> bit.
>>      */
>>     result = (map[mapByte] & (1 << mapBit)) ? true : false;
>>
>>
>> Isn't this a dangerous assumption to make ? I am not so sure that even 
>> a bit
>> can be read atomically on all platforms. 
> 
> Umm, what non-atomic state could the bit be in? Half-set, half-cleared? 
> Or do you think that if some other bit in proximity is changed, the 
> other bit would temporarily flip 0->1->0, or something like that? I 
> don't think that should happen.
> 

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. I think 
we use same principle for TransactionID?

    Zdenek

* Wide is architecture dependent. and of course it depends on alignment. I'm not 
sure how x86 CPUs read nonalignment memory. But if you enable this on SPARC it 
is handled in software thru TRAP handlers and it is not really atomic. But in 
our case we use byte access which is safe everywhere.

** IIRC, some AMD64 processors allows to disable cache coherence check, but it 
not used in standard OS, and we can ignore it.




pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Sync Rep: First Thoughts on Code
Next
From: Peter Eisentraut
Date:
Subject: Refactoring SearchSysCache + HeapTupleIsValid