Something is going wrong with code generation here, potentially the
inline assembly generated by _arch_irq_un/lock(), and these calls are
not being inlined by gcc. So what should be a ~3 instruction sequence
on most uniprocessor architectures is turning into 8-20 cycles worth
of work to implement the API as written.
Use an ALWAYS_INLINE, which is sort of ugly semantically but produces
much better code.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There was an existing validation layer in the spinlock implementation,
but it was only enabled when both SMP and CONFIG_DEBUG were enabled,
which meant that nothing was using it. Replace it with a more
elaborate framework that ensures that every lock taken is not already
taken by the current CPU and is released on the same CPU by the same
thread.
This catches the much more common goof of locking a spinlock
recursively, which would "work" on uniprocessor setups but have the
side effect of releasing the lock prematurely at the end of the inner
lock. We've done that in two spots already.
Note that this patch causes k_spinlock_t to have non-zero size on
builds with CONFIG_ASSERT, so expect a little data and code size
increase. Worth it IMHO.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Any word started with underscore followed by and uppercase letter or a
second underscore is a reserved word according with C99.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Minimal spinlock API based on the existing atomic.h layer. Usage
works just like irq_lock(), but takes an argument to a specific struct
k_spinlock_t to un/lock. No attempt at implementing fairness or
backoff semantics. No attempt made at architecture-specific assembly.
When CONFIG_SMP is not enabled, this code falls back to a zero-size
struct and becomes functionally identical to irq_lock/unlock().
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Andy Ross