Pete Zaitcev (zaitcev) wrote,
Pete Zaitcev

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).

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.


  • Scalability of a varying degree

    Seen at official site of Qumulo: Scale Platforms must be able to serve petabytes of data, billions of files, millions of operations, and…

  • MinIO liberates your storage from rebalancing

    MinIO posted a blog entry a few days ago where the bragged about adding capacity without a need to re-balance. First, they went into a full…

  • Swift in 2021

    A developer meet-up for OpenStack, known as PTG, occurred a week ago. I attended the Swift track, where somewhat to my surprise we had two new…

  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded