Remove SpinLockFree() / S_LOCK_FREE()?

Started by Andres Freundalmost 6 years ago2 messageshackers
Jump to latest
#1Andres Freund
andres@anarazel.de

Hi,

We currently have
* bool SpinLockFree(slock_t *lock)
* Tests if the lock is free. Returns true if free, false if locked.
* This does *not* change the state of the lock.
and its underlying S_LOCK_FREE() operation:
*
* bool S_LOCK_FREE(slock_t *lock)
* Tests if the lock is free. Returns true if free, false if locked.
* This does *not* change the state of the lock.

They are currently unused and, as far as I can tell, have never been
used outside test code /asserts. We also don't currently implement them
in the spinlock fallback code:

bool
s_lock_free_sema(volatile slock_t *lock)
{
/* We don't currently use S_LOCK_FREE anyway */
elog(ERROR, "spin.c does not support S_LOCK_FREE()");
return false;
}

I also find the "free" in the name very confusing. Everytime I look at
them (which, I grant, is not that often), I have to think about what
they mean.

Thus: Let's just remove SpinLockFree() / S_LOCK_FREE()?

Greetings,

Andres Freund

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andres Freund (#1)
Re: Remove SpinLockFree() / S_LOCK_FREE()?

Andres Freund <andres@anarazel.de> writes:

We currently have
* bool SpinLockFree(slock_t *lock)
* Tests if the lock is free. Returns true if free, false if locked.
* This does *not* change the state of the lock.
[ which isn't used ]
Thus: Let's just remove SpinLockFree() / S_LOCK_FREE()?

Yeah. I think they were included in the original design on the
theory that we'd need 'em someday. But if we haven't found a use
yet we probably never will. So +1 for narrowing the API a tad.

(We'd lose some error checking ability in the S_LOCK_TEST code,
but probably that's not worth worrying about.)

regards, tom lane