Thread: Remove SpinLockFree() / S_LOCK_FREE()?

Remove SpinLockFree() / S_LOCK_FREE()?

From
Andres Freund
Date:
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



Re: Remove SpinLockFree() / S_LOCK_FREE()?

From
Tom Lane
Date:
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