tests: kernel: spinlock: Added busy wait of 5us

[sswetha18]

This commit adds a busy wait of 5us in the
test_trylock testcase to address timing
inconsistencies observed on high clock speed
platforms.

Faster execution on these platforms causes the
lock to be acquired consistently, preventing
expected failure cases. Introducing a brief
busy wait adjusts timing, allowing failures to
occur as intended and ensuring consistent
test behavior across platforms.

[cfriedt]

Could ticket spin locks help here?

[npitre]

Ticket spin locks won't change anything. Problem is about the test itself being flawed. It is not condusive to lock contention. If given thread was the last lock owner, it releases the lock right away and waits for 100 us before trying again. If given thread was not the lock owner then it marks itself as the owner, loops 5 times for 1 us and releases the lock, to reacquire it right away just to notice it was the last owner and release the lock to wait for 100 us. So you have 95% chances that at the end of your 100 us wait period, the other thread would have acquired the lock, waited its 5 us with the lock held, then release+acquire+release and be in the middle of its own 100 us waiting period as well with the lock uncontended. In other words, probability of lock contention is only 5%. I'm pretty sure that's not what the actual intent of this test is. The proposed fix is merely creating an imbalance so that one thread would wait 105 us instead of 100 so once every so often both threads would be synchronized and attempt to acquire the lock simultaneously. That's one way to "fix" it and it should probably be done for the non trylock as well so the non trylock version gets its chance at experiencing a few contentions too. But I think it'd be better if the test was reworked so to significantly increase the odds for contention instead.

[sswetha18]

Ticket spin locks won't change anything. Problem is about the test itself being flawed. It is not condusive to lock contention. If given thread was the last lock owner, it releases the lock right away and waits for 100 us before trying again. If given thread was not the lock owner then it marks itself as the owner, loops 5 times for 1 us and releases the lock, to reacquire it right away just to notice it was the last owner and release the lock to wait for 100 us. So you have 95% chances that at the end of your 100 us wait period, the other thread would have acquired the lock, waited its 5 us with the lock held, then release+acquire+release and be in the middle of its own 100 us waiting period as well with the lock uncontended. In other words, probability of lock contention is only 5%. I'm pretty sure that's not what the actual intent of this test is. The proposed fix is merely creating an imbalance so that one thread would wait 105 us instead of 100 so once every so often both threads would be synchronized and attempt to acquire the lock simultaneously. That's one way to "fix" it and it should probably be done for the non trylock as well so the non trylock version gets its chance at experiencing a few contentions too. But I think it'd be better if the test was reworked so to significantly increase the odds for contention instead.

Acknowledged. I will work on a fundamental rework to improve lock contention consistency