Re: visibility maps

Поиск
Список
Период
Сортировка
От Zdenek Kotala
Тема Re: visibility maps
Дата
Msg-id 4940FA0F.50008@sun.com
обсуждение исходный текст
Ответ на Re: visibility maps  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: visibility maps  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Sync Rep: First Thoughts on Code
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Refactoring SearchSysCache + HeapTupleIsValid