1. 13
  1.  

  2. 7

    Geeze Apple. This is “introduction to operating systems” level stuff. There are examples of working systems, mostly realtime, where high priority threads never get preempted and you must be very careful about spin locks. But they are like that to start, and clearly documented. It’s problematic to retrofit such a design into a system that previously always had preemptible threads.

    1. 3

      In what cases are spinlocks not a bad idea? I mean seriously this is like asynchronous programming 101 stuff. I suppose if the underlying architecture makes real locks impossible but how many of those are there outside of niche embedded systems are there?

      [Edit] This is a serious question by the way. I’m really interested in what situations would make a spinlock be preferable.

      1. 3

        They’re a fast synchronization primitive, so e.g. locks for a kernel’s scheduler would want to use them.

        1. 2

          See the “Spinlock performance” section of the linked article.

          If your critical sections are non-blocking (and generally short) they’re likely to be more efficient than “real” (blocking/sleeping) locks. Even if your critical sections are long and/or blocking, they’ll be inefficient, but still safe…unless, as is apparently the case here, your system’s scheduler has starvation problems designed in (leading to lockups).

          1. 1

            OpenMP libraries, for example.

            1. 1

              I don’t have enough context to understand this answer.