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:
parent
c73980654c
commit
8d7c274e55
3 changed files with 15 additions and 4 deletions
|
@ -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;
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue