ck_dec spinlock can acquire the already-acquired lock.

[multics69]

ck_dec spinlock can acquire the lock that is already acquired. You can reproduce the problem using the following code snippet, which is modified from ck/regressions/ck_spinlock/validate/validate.h. The underflow of lock->value at ck_spinlock_dec_lock_eb() is the root cause of the problem.

======= code to reproduce =======

LOCK_DEFINE;

int
main(int argc, char *argv[])
{
#ifdef LOCK_INIT
        LOCK_INIT;
#endif
#ifdef LOCK_STATE
        LOCK_STATE;
#endif
        printf("[1] try to acquite the lock\n");
        LOCK;
        printf("[2] the lock is acquired\n");

        printf("[3] try to acquite the lock\n");
        LOCK;
        printf("[4] the lock is acquired\n");
        return (0);
}

======= output =======

[1] try to acquite the lock
[2] the lock is acquired
[3] try to acquite the lock
[4] the lock is acquired

[sbahra]

Thanks for the PR! This is specific to lock_eb, specifically, since we don't busy-wait after lock_eb, the number of decrement operations is always unbounded. This is now fixed in master. Note the core algorithm has no guarantees on bound (in case of extreme starvation, underflow is still possible but it's very unlikely to occur).

[multics69]

Thank you!

[sbahra]

Out of curiosity, what are you working on? Always love to hear about use-cases / research.

[multics69]

I am working on developing a performance profiler to find spinlock contention. Since concurrency kit already has all sort of spinlocks with great unit test cases, I am using CK for unit test cases of my performance profiler. Thank you!