Re: drop volatile from __cpu_simplelock_t typedef

[Matt Thomas <matt%3am-software.com@localhost>]

> On Jun 26, 2015, at 6:55 AM, Antti Kantee <pooka%iki.fi@localhost> 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.