Re: atomics: document that linux expects certain atomic behaviour from unsigned long

[Robert Hancock <hancockr@shaw.ca>]

Pavel Machek wrote:
> On Sat 2009-01-03 20:30:44, Alan Cox wrote:
>>> If it is okay and linux relies on it, it should be documented.
>>>
>>> If it is not okay, I guess we should document it, too -- it seems to
>>> be common mistake. 
>> A lot of old code did it knowing it was under the BKL, outside of the BKL
>> its a very bad idea. There were lots of them in the tty layer and I don't
>> doubt there are some left I missed too 8(
> 
> I have seen this in new code (some LED driver last time), definitely
> no BKL.
> 
> Is there concrete architecture where it breaks? I'd expect i386/x86-64
> to be safe, and pretty much everyone to be safe as long as that long
> is aligned.... or that was the result of arch-maintainers
> discussion...
> 
> I'd really like to document if it is right or not, so that I can point
> people to documentation...
> 								Pavel

If you look at the atomic implementation on x86 all it does is assign 
and read the internal int variable directly for atomic_set and 
atomic_read, so I suppose it would be OK to just use a normal variable 
in that case.. but then there's no performance hit so you might as well 
use atomic_t anyway. On some architectures like arm and sparc there is 
some magic involved in atomic_set and/or atomic_read (but those may just 
be to guard against other concurrent atomic ops, I'm not sure).

Certainly unless the code is really performance critical there is no 
point messing around, just use an atomic if it needs to be accessed 
without locking. Note that memory barriers may be an issue as well..