Pete Zaitcev (![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small} zaitcev) wrote,@ 2007-05-30 16:44:00 |
|
spin_lock bracket
Roland (Dreier, not McGrath) sure likes crusading for code style. Sometimes it produces good results, like when he tilts at windmills powered by __attribute__((packed)). One recent thing he posted was a rant about the proper use of atomic_t. I agree with his point on the whole, but in spinlock case I think he misses something important: spinlocks include optimization barriers, whereas atomic_t only includes CPU barriers (where needed — not on x86). Therefore, in Linux kernel it's possible to guard a bunch of state with a boolean flag under a spinlock (but not with an atomic).
Roland (Dreier, not McGrath) sure likes crusading for code style. Sometimes it produces good results, like when he tilts at windmills powered by __attribute__((packed)). One recent thing he posted was a rant about the proper use of atomic_t. I agree with his point on the whole, but in spinlock case I think he misses something important: spinlocks include optimization barriers, whereas atomic_t only includes CPU barriers (where needed — not on x86). Therefore, in Linux kernel it's possible to guard a bunch of state with a boolean flag under a spinlock (but not with an atomic).
Some time ago (heck, it was in late 90s, IIRC), DaveM did a presentation to a group called "Desktop Performance Council" at Sun, which pretty much was themed "Why Solaris Sucks". I'm sure it was an entertaining session. At the time he identified the spinlock bracket, such as Roland mentioned, to be detrimental, and pronounced the use of atomic_t superior.
Unfortunately, this was in days of gcc 2.7.2, when we were far more lax about optimization barriers, and since atomic_t did not gain barriers, it cannot be used like spinlocks can, when gcc 4 flexes its muscle. So my recent usblp patch uses spinlocks exactly the way DaveM lampooned as Solaris' foolishness 10 years ago.
