Re: testing HS/SR - 1 vs 2 performance - Mailing list pgsql-hackers

From Tom Lane
Subject Re: testing HS/SR - 1 vs 2 performance
Date
Msg-id 4927.1272216804@sss.pgh.pa.us
Whole thread Raw
In response to Re: testing HS/SR - 1 vs 2 performance  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: testing HS/SR - 1 vs 2 performance  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> On Sun, 2010-04-25 at 12:51 -0400, Tom Lane wrote:
>> If the comments were correct, I wouldn't be complaining.  They're
>> misleading or outright wrong on many points.  In particular, I don't
>> think you actually understand the weak-memory-ordering issue, because
>> the comments about that are entirely wrong.  

> The comments says "on CPUs with
> + * weak-memory ordering we can't reliably move pointers atomically, so
> the
> + * rule is that updates of head and tail of the array require
> ProcArrayLock
> + * in exclusive mode or (shared mode and known_assigned_xids_lck
> spinlock)"

> I will reword this, so it is clear that I'm talking about the head and
> tail of the array, not pointers in general.

It's not about whether the pointers can be assigned atomically; on most
hardware they can.  It's about whether other processors will see that
happen in the correct sequence relative to the changes in the array
elements.

If you like I'll have a go at rewriting the comments for this patch,
because I am currently thinking that the problem is not so much with
the code as with the poor explanation of what it's doing.  Sometimes
the author is too close to the code to understand why other people
have a hard time understanding it.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: testing HS/SR - 1 vs 2 performance
Next
From: Simon Riggs
Date:
Subject: Re: testing HS/SR - 1 vs 2 performance