Interaction between CSpinLock and CLogger

[diyelectromusic]

As part of MiniDexed, there are several spinlocks created, but it would appear that in the MIDI driver after the MIDI spinlock has been acquired (https://github.com/probonopd/MiniDexed/blob/main/src/mididevice.cpp#L171) calls to any of the LOGn macros/functions no longer output to the display until the spinlock has been released.

Is this expected behaviour?

I see that the CLogger has its own spinlocks, so I guess my question really is - should different spinlocks be independent of each other?

Thanks,
Kevin

[rsta2]

In a multi-core environment acquiring a spin lock does two things:

• It raises the current execution level to the level, given in its constructor (by default IRQ_LEVEL). This is the highest level, the spin lock can be acquired in the application. Raising the execution level prevents deadlocks, because when a spin lock is held and for example an IRQ occurs and the IRQ handler tries to acquire the same spin lock on the same core, this would freeze the system. So with IRQ_LEVEL given to the constructor of a spin lock, IRQs are prohibited on this core as long this spin lock is acquired.
• A lock variable is tested and set in an atomic operation. The acquire operation spins in a loop until, it can set the lock variable and it wasn't set before. If this succeeds, it owns the spin lock. The lock variable ensures, that only one core in the multi-core environment can hold the spin lock at a time.

Releasing the spin lock does this:

• It clears the lock variable.
• It lowers the execution level to the level, which was active, before the spin lock was acquired.

Because spin locks normally disable the IRQ, they should be held as short as possible. With the REALTIME system option set, the screen device driver suppresses writes to it, as long IRQs are disabled, because when the screen driver has to scroll inside the write operation with IRQ disabled for example, this may take several milliseconds and may result in a bad timing of an application.

MiniDexed enables the REALTIME system option here. For debugging purpose you can remove the -o REALTIME option in this line and the log messages will appear after re-build.

Spin locks are independent regarding to its lock variable, but not to the execution level, which is set, when a spin lock is acquired.

[diyelectromusic]

Great - many thanks for that explanation - that makes a lot more sense now :)

Kevin

[diyelectromusic]

Thinking about this some more... once the lock is acquired, wouldn't the execution level drop again? Presumably interrupts only need to be disabled to ensure the integrity of the atomic operation to acquire and release the lock, but once acquired and released they shouldn't be needed to keep it...?

I'm a bit rusty, but I thought that is how a semaphore in an RTOS would work and I'd read into SpinLocks that they were effectively the same thing... otherwise you wouldn't need locks, we could just disable interrupts :)

Or am I still misunderstanding elements of how this is intended to work?

I am working on the basis that the MIDI driver in MiniDexed uses a spinlock to stop multiple input sources interrupting each other when parsing messages. If so, then the spinlock is being used to avoid a proper message queue I guess, which perhaps isn't ideal in itself anyway...

Thanks!
Kevin

[rsta2]

No, the atomic operation is ensured by a special CPU instruction. After the lock is acquired, there could be still a deadlock, when the execution level would drop, there would occur an IRQ and the IRQ handler tries to acquire the same spin lock.

I don't know, where you read, that semaphores and spin locks are basically the same thing? Circle also supports semaphores, but this is for task synchronization, while spin locks are a method for the synchronization of multiple cores in a multi-core environment, where tasks/threads are not available.

Yes, in a single-core environment, you could simply disable the IRQ, instead of using a spin lock, and actually the Circle spin lock is implemented this way, when ARM_ALLOW_MULTI_CORE is not defined.

This m_MIDISpinLock was not there, when I was contributing to MiniDexed. I'm not sure, why it was added.

[diyelectromusic]

I suspect a synchronisation mechanism in this case is probably more what is required, but without knowing why it was put there I'm reluctant to change it. It's not a big deal.

Thanks for the explanations!

Kevin