Robert Haas <robertmh...@gmail.com> writes:
> On Sun, Aug 28, 2011 at 11:35 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmh...@gmail.com> writes:
>>> Then, I did this:
>>>
>>> - while (TAS(lock))
>>> + while (*lock ? 1 : TAS(lock))
>> Er, what? That sure looks like a manual application of what you'd
>> already done in the TAS macro.
> Sorry, I blew through that a little too blithely. If you change TAS()
> itself, then even the very first attempt to acquire the lock will try
> the unlocked instruction first, whereas changing s_lock() allows you
> to do something different in the contended case than you do in the
> uncontended case.
Yeah, I figured out that was probably what you meant a little while
later. I found a 64-CPU IA64 machine in Red Hat's test labs and am
currently trying to replicate your results; report to follow.
> We COULD just change the TAS() macro since, in this
> case, it seems to make only a minor difference, but what I was
> thinking is that we could change s_lock.h to define two macros, TAS()
> and TAS_SPIN().
Yeah, I was thinking along the same lines, though perhaps the name of
the new macro could use a little bikeshedding.
The comments in s_lock.h note that the unlocked test in x86 TAS is of
uncertain usefulness. It seems entirely possible to me that we ought
to use a similar design on x86, ie, use the unlocked test only once
we've entered the delay loop.
>> Please clarify: when you say "this architecture", are you talking about
>> IA64 or PA-RISC? Is there any reason to think that this is specific to
>> HP-UX rather than any other system on the same architecture? (I'm sure
>> I can get access to some IA64 clusters at Red Hat, though maybe not
>> 64-core ones.)
> I tested on IA64; I don't currently have access to a PA-RISC box. The
> documentation I'm looking at implies that the same approach would be
> desirable there, but that's just an unsubstantiated rumor at this
> point....
Well, I've got a PA-RISC box, but it's only a single processor so it's
not gonna prove much. Anybody?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
