On Wed, Sep 12, 2012 at 4:08 PM, Noah Misch <noah@leadboat.com> wrote:
On Wed, Sep 12, 2012 at 06:44:37AM -0400, Gurjeet Singh wrote: > Thinking a bit more about the need for locks, I guess even the shared > variables whose read/write ops are considered atomic need to be protected > by locks so that the effects of NUMA architectures can be mitigated.
src/backend/storage/lmgr/README.barrier has nice coverage of such issues.
NUMA does not change the picture. CPU architecture specifications define ordering constraints for instructions that touch memory. NUMA is a property of specific system implementations that changes performance characteristics, but not functional guarantees, of those instructions.
I read-up a bit more on the topic, and it seems that the pure NUMA based machines have never been sold in the market, quite possibly because of the difficulty to write programs for them. The NUMA machines in use are effectively ccNUMA (cc for cache-coherent).
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 guarantees provided by ccNUMA and those provided by non-ccNUMA (regular NUMA). I may be totally off here, so please correct me if needed.
