Re: LWLockWaitUntilFree (was: Group commit, revised) - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: LWLockWaitUntilFree (was: Group commit, revised)
Date
Msg-id CAMkU=1zpw6-oYnwDe18v2vnRm_GewJOsEmicBRATa3M4kwdnbQ@mail.gmail.com
Whole thread Raw
In response to Re: LWLockWaitUntilFree (was: Group commit, revised)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Feb 3, 2012 at 12:57 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> I think I recommended a bad name for this function.  It's really
> LWLockAcquireOrWaitUntilFree.  Can we rename that?
>
> We might also want to consider what all the behaviors are that we
> might want here.  It strikes me that there are two possible actions
> when a lock is immediately available (acquire or noop) and three
> possible actions when it isn't (wait-then-acquire, wait-then-noop, or
> immediate-noop), for a total of six possible combinations:
>
> acquire/wait-then-acquire = LWLockAcquire
> acquire/wait-then-noop = what you just added
> acquire/immediate-noop = LWLockConditionalAcquire
> noop/wait-then-acquire
> noop/wait-then-noop
> noop/immediate-noop
>
> The last one is clearly pointless, since you don't need a lock at all
> to do nothing.  But is there a use case for either of the other two?

You've only considered things with the same mode on each side of the
"/".  One thing that I've wanted is:
acquire-exclusive-immediate-and-return-true/wait-then-acquire-shared-and-return-false.

The idea was that there is something that I need to verify has been
done, but it doesn't matter who did it.  To do the work, I need
exclusive, but to verify that the work has already been done I only
need shared.  So, if I don't get the exclusive lock, then by the time
I can get it the work has probably been done by someone else so I only
need a shared lock to verify that.

Come to think of it, I think what I wanted my behavior for was for
this very thing that inspired this WaitUntilFree, improving
group-commit.  But I see in this case the verification is being done
under a spinlock rather than a shared LWLock.  I don't know if there
is any case left over for my proposed behavior, or if spinlock
verification would always be easy to arrange so as to make it
pointless.

Cheers,

Jeff


pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Checkpoint sync pause
Next
From: Jeff Janes
Date:
Subject: Re: Group commit, revised