On Thu, 2004-11-25 at 11:28, Neil Conway wrote:
> Simon Riggs wrote:
> > I'd been thinking about lock release order also, thinking that this
> > could be related to the CS storms observed earlier and the apparent
> > lock-step behaviour commented upon previously.
>
> As much as I would love to believe this (because it would mean we could
> probably solve the problem pretty easily), I don't think lock release
> order is the (primary) culprit behind the CS storm issue.
Wish we had a way to tell... though I think you are right.
> As I
> understand it, the heavily contended lock in those situations is the
> BufMgrLock, and that is _always_ acquired in exclusive mode.
So you're saying this doesn't effect BufMgrLock contention? Oh.
> > ISTM that waking
> > shared waiters in xid order would bring the most benefit and minimise
> > any data issues. Readers waiting behind an exclusive waiter, where the
> > reader has a lower xid might reasonably be woken without a problem since
> > they will never see the changes made by the exclusive waiter anyway.
>
> I'm not sure I understand. What "data issues" are you referring to?
> LWLocks are used to protect non-transactional resources (such as shared
> memory data structures), so the relative xids of two waiter processes
> doesn't affect whether they can see each other's modifications (i.e.
> because they always can).
Yes, understand the difference. But when we check for tuple visibility,
the changes would be ignored, hence it is OK to resort the list from
FIFO to xid order, but...
> In any case, the idea of considering information such as the xid when
> deciding which waiters to release is interesting. It's not immediately
> apparent to me quite *how* to make use of that info, but it's definitely
> something to consider...
Agreed.
It's a wacky idea and I'm not embarrassed having them. The day I stop
having them will be the day I stop having good ideas too. But please
don't let this distract from your own good-idea:
Well done to you, Neil.
--
Best Regards, Simon Riggs
