OSDev.org

Hi to everybody!

My question is fairly simple: is it a good idea to test the sync primitives (in this case, spinlocks) of your OS in a normal C program?

For example I would like to create four threads using the pthread library to simulate different CPUs accessing (dummy) kernel functions to catch any concurrency issues; but, rather than using pthread primitives I'd like to use my spinlock implementation.

In your opinion is this possible or the underlying operating system would interfere with the spinlocks?
Obviously the only type of spinlock that can be tested are those which only delay-loop and don't touch IRQs...

Thanks in advance,

Teo

Hi,

nop wrote:In your opinion is this possible or the underlying operating system would interfere with the spinlocks?

For testing if the spinlocks work correctly, there shouldn't be any problems testing it this way.

For testing any type of performance; because the OS wouldn't know anything about it, CPUs could be busy spinning (trying to get the lock) while whoever actually has acquired the lock isn't even running and can't/won't release the lock. The end result might be frequent "lock contention spikes" that ruin the results.


Cheers,

Brendan

Brendan wrote:For testing if the spinlocks work correctly, there shouldn't be any problems testing it this way.

Hi Brendan,
thank you! I'll start testing asap!

Teo

It could be a good complement, but spinlocks really couldn't be fully tested in a user-thread environment in another OS. The basic function to be able to synchronize between CPUs and ISRs would be untestable, and you really don't know if your target OS runs your threads on different cores, even if your target machine is multicore.

I would at least want to make some good, native, tests on my own OS before I would be certain that they really work there.

There are well-tested spinlock code for most processor(including x86, x86_64 and ARM).
If you are unsure, use the standard, there is little room for improvement, or you design might be 100% identical to the standard one anyway.

bluemoon wrote:There are well-tested spinlock code for most processor(including x86, x86_64 and ARM).
If you are unsure, use the standard, there is little room for improvement, or you design might be 100% identical to the standard one anyway.

That's true, but one might have special considerations, like only using 386 instructions (which excludes cmpxchg). I also think I will implement a loop-counter to be able to detect spinlocks that never are released, and either rebooting (production release) or invoking crash debugger (debug release). Otherwise, the system will just die with no diagnostics.

rdos wrote:

bluemoon wrote:There are well-tested spinlock code for most processor(including x86, x86_64 and ARM).
If you are unsure, use the standard, there is little room for improvement, or you design might be 100% identical to the standard one anyway.

That's true, but one might have special considerations, like only using 386 instructions (which excludes cmpxchg). I also think I will implement a loop-counter to be able to detect spinlocks that never are released, and either rebooting (production release) or invoking crash debugger (debug release). Otherwise, the system will just die with no diagnostics.

spinlock is by definition has no timeout counter - it is designed to lock/unlock quickly, if you expect it to support timeout, you are misusing spinlock and you should use mutex in such case.
And to detect deadlock, is that what watchdog is designed for?

(NOTE: providing return value for caller to check return code may be possible, but this is just too much overhead to justify).

PS. However, when implementing mutex/futex, a logic similar with spinlock with counter may be used (see CreateCriticalSectionAndSpinCount), however, strictly speaking, that is not spinlock.

It would be a pure debug / deadlock detection issue, so there would be no return code. The spinlock code would itself call the fatal error handler (crash debugger) when it has run the loop too many times.

By the way, I cannot imagine deadlock scenario for spinlock... I only use spinlock for setting flags, and never put jumps inside the lock, maybe it's just me.

But on second thought, you made a point too, a counter may signal lock contingency.

Spinlocks works in user mode as well as in kernels. You can add time outs and everything if you want in order to catch errors.

There is an important difference with spinlocks in user space versus in the kernel. In the kernel before entering a spinlock, interrupts are often disabled in order to avoid dead locks and long lock periods. In a user space program, you might not have the luxury to disable the interrupts because it is prohibited. This can lead to that preemption or interrupts happens in the middle of a lock, locking for a quite long time preventing other processors to gain access to the resource. Therefore in user space programs semaphores are a bit more attractive than they are in the kernel.

In order to avoid this interrupt problem in user space, lock less algorithms are starting to become more popular. Both AMD and Intel are now implementing lock and commit buffers in their processors so that more complicated algorithms can be made lock less.