Horton

Thread

Commits

  1. Remove SpinLockFree() and S_LOCK_FREE().

  1. Remove SpinLockFree() / S_LOCK_FREE()?

    Andres Freund <andres@anarazel.de> — 2020-06-08T22:53:38Z

    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

  2. Re: Remove SpinLockFree() / S_LOCK_FREE()?

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-06-08T23:00:26Z

    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