<div dir="ltr"><div class="gmail_quote">On Wed, Sep 12, 2012 at 4:08 PM, Noah Misch <span dir="ltr"><<a
href="mailto:noah@leadboat.com"target="_blank">noah@leadboat.com</a>></span> wrote:<br /><blockquote
class="gmail_quote"style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Sep
12,2012 at 06:44:37AM -0400, Gurjeet Singh wrote:<br /> > Thinking a bit more about the need for locks, I guess even
theshared<br /> > variables whose read/write ops are considered atomic need to be protected<br /> > by locks so
thatthe effects of NUMA architectures can be mitigated.<br /><br /></div>src/backend/storage/lmgr/README.barrier has
nicecoverage of such issues.<br /><br /> NUMA does not change the picture. CPU architecture specifications define<br
/>ordering constraints for instructions that touch memory. NUMA is a property<br /> of specific system implementations
thatchanges performance characteristics,<br /> but not functional guarantees, of those instructions.<br
/></blockquote></div><br/>I read-up a bit more on the topic, and it seems that the pure NUMA based machines have never
beensold in the market, quite possibly because of the difficulty to write programs for them. The NUMA machines in use
areeffectively ccNUMA (cc for cache-coherent).<br /><br />So when people talk about NUMA (like, I think you are doing
above),they mean the ccNUMA. So, based on what little I know about it, I think there are differences between functional
guaranteesprovided by ccNUMA and those provided by non-ccNUMA (regular NUMA). I may be totally off here, so please
correctme if needed.<br /><br /><a
href="http://en.wikipedia.org/wiki/Non-Uniform_Memory_Access#Cache_coherent_NUMA_.28ccNUMA.29">http://en.wikipedia.org/wiki/Non-Uniform_Memory_Access#Cache_coherent_NUMA_.28ccNUMA.29</a><br
/>--<br /><div dir="ltr">Gurjeet Singh<br /><br /><a href="http://gurjeet.singh.im/"
target="_blank">http://gurjeet.singh.im/</a><br/></div><br /></div>
