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