Re: Correction to comment regarding atomicity of an operation

On Wed, Sep 12, 2012 at 4:08 PM, Noah Misch <noah(at)leadboat(dot)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.

http://en.wikipedia.org/wiki/Non-Uniform_Memory_Access#Cache_coherent_NUMA_.28ccNUMA.29
--
Gurjeet Singh

http://gurjeet.singh.im/