> On Jun 26, 2015, at 6:55 AM, Antti Kantee <po...@iki.fi> wrote: > > __cpu_simplelock_t was born 15+ years ago with the following commit message: > > === snip === > Let each platform typedef the new __cpu_simple_lock_t, which should > be the most efficient type used for the atomic operations in the > simplelock structure, and should also be __volatile. > === snip === > > So, thinking about fixing lib/49989, I started wondering why "volatile" is > necessary in the simplelock typedefs. "should also be" doesn't explain much, > and may just be there because that's what the pre-simplelock_t definitions > used. Shouldn't simplelocks always be operated on with atomic instructions > and instruction barriers or some non-SMP equivalent thereof? Assuming so, > volatile in the typedef doesn't do anything except probably throw compilers > off and therefore we should drop volatile from the typedefs. > > RAS might need volatile (not sure yet), but that can probably be pushed > inside the RAS sequence instead of exposing it everywhere. > > Thoughts? Seems like the right thing to do irrespective of lib/49989.
__cpu_simpe_lock_unlock concerns me without volatile. Also, many have loops that count on the variable changing. Without volatile those will become infinite loops. For RISC-V, I used the builtin C11-ish gcc atomics to implement the __cpu_simple_lock_t operations. I just moved it to <sys/common_lock.h> so other ports could use it.
