lkml.org 
[lkml]   [2009]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: atomics: document that linux expects certain atomic behaviour from unsigned long
On Sat 2009-01-03 20:19:55, Alan Cox wrote:
> On Sat, 3 Jan 2009 13:44:00 +0100
> Pavel Machek <pavel@suse.cz> wrote:
>
> > Linux relies on unsigned long to behave like atomic for read/write.
>
> Actually it isn't that simple and this advice shouldn't be given IMHO.
>
> unsigned long is not the same as atomic in several respects including
> ordering and caching of the result.

I'm confused. I remember distinctly being told, when merging the
Gigaset driver, that reading and writing of "pointer sized objects"
(I specifically remember that term) was assumed to be atomic across
large parts of the kernel anyway, that locking around a single read
or write of such an item was therefore pointless, and that "atomic_t"
only made sense if I wanted to use atomic_inc or atomic_dec on them.
The patches I submitted in following that advice, specifically commit
4d1ff582246de67b15e3cd2427a39875943ae895 "gigaset: remove pointless
locking" and 9d4bee2b9de9e30057a860d2d6794f874caffc5e "gigaset: atomic
cleanup", were confirmed to do the right thing and merged without any
objection.

What am I missing?

Thanks,
Tilman

--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2009-01-04 19:23    [W:0.076 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site