kernel/sched: protect thread sched_lock with compiler barriers

This has not bitten us yet, but it was a ticking timebomb.

This is similar to the issue that was found with irq_lock/irq_unlock
implementations on several architectures. Having a volatile variable is
not the way to force the sched_lock variable to be
incremented/decremented around the accesses to data it protects.
Instead, a compiler barrier must prevent the compiler from reordering
the memory accesses around setting of sched_lock. Needed in the inline
implementations _sched_lock()/_sched_unlock_no_reschedule(), which
resolve to simple decrement/increment of the per-thread sched_lock
variable.

Change-Id: I06f5b3524889f193efe69caa947118404b1be0b5
Signed-off-by: Benjamin Walsh <walsh.benj@gmail.com>
This commit is contained in:
Benjamin Walsh 2017-02-11 10:50:27 -05:00 committed by Anas Nashif
commit 8d7c274e55
3 changed files with 15 additions and 4 deletions

View file

@ -93,11 +93,11 @@ struct _thread_base {
union {
struct {
#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
volatile uint8_t sched_locked;
uint8_t sched_locked;
int8_t prio;
#else /* LITTLE and PDP */
int8_t prio;
volatile uint8_t sched_locked;
uint8_t sched_locked;
#endif
};
uint16_t preempt;