From: | Florian Pflug <fgp(at)phlo(dot)org> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: spinlock contention |
Date: | 2011-07-14 00:40:20 |
Message-ID: | 235FE53E-7764-40E6-B766-B6F812A629C0@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jul13, 2011, at 22:04 , Robert Haas wrote:
> On Jul 12, 2011, at 8:10 PM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
>> I wonder if clearing the waiters-present bit only upon clearing the
>> queue completely is necessary for correctness. Wouldn't it be OK
>> to clear the bit after waking up at least one locker? That'd still
>> guarantee that you cannot end up with a blocked process but no lock
>> holder, I believe.
>
> I don't think so - how does the next process that releases the lock
> know to release waiters?
It won't :-(. Not that easily, at least.
The idea stemmed from that fact that my shared counter partitioning
patch get away with something similar. But that only works because it
always re-checks for possible interference after doing the fast path,
so the idea isn't directly applicable to your patch it seems.
Porting that idea to your CAS patch would probably make it nearly
identical to the shared-counter partitioning patch with the number of
partitions set to 1, so I see little point in that.
BTW, I think I got a workable atomic queue that suits our needs sketched
up - it'll post the details once I've convinced myself that it's actually
correct. So should you believe that approach to be unworkable for some
reason, please speak up and same me the effort.
best regards,
Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2011-07-14 00:42:38 | Three patches which desperately need reviewers |
Previous Message | Florian Pflug | 2011-07-14 00:12:28 | Re: proposal: a validator for configuration files |