Spinning around: Please don't – Common problems with spin locks

▲ Spinning around: Please don't – Common problems with spin locks(siliceum.com)

30 points by bdash 4 hours ago | 9 comments

▲ jcranmer 30 minutes ago | parent | next [-]

The basic rule of writing your own cross-thread datastructures like mutexes or condition variables is... don't, unless you have very good reason not to. If you're in that rare circumstance where you know the library you're using isn't viable for some reason, then the next best rule is to use your OS's version of a futex as the atomic primitive, since it's going to solve most of the pitfalls for you automatically.

The only time I've manually written my own spin lock was when I had to coordinate between two different threads, one of which was running 16-bit code, so using any library was out of the question, and even relying on syscalls was sketchy because making sure the 16-bit code is in the right state to call a syscall itself is tricky. Although in this case, since I didn't need to care about things like fairness (only two threads are involved), the spinlock core ended up being simple:

    "thunk_spin:",
        "xchg cx, es:[{in_rv}]",
        "test cx, cx",
        "jnz thunk_has_data",
        "pause",
        "jmp thunk_spin",
    "thunk_has_data:",

	▲	kccqzy 23 minutes ago \| parent [-]
		Another time when writing a quick and dirty spinlock is reasonable is inside a logging library. A logging library would normally use a full-featured mutex, but what if we want the mutex implementation to be able to log? Say the mutex can log that it is non recursive yet the same thread is acquiring it twice; or that it has detected a deadlock. The solution is to introduce a special subset of the logging library to use a spinlock.

▲ CamperBob2 an hour ago | parent | prev | next [-]

Sheesh. Can something this complicated ever truly be said to work?

▲

nh23423fefe 38 minutes ago | parent | next [-]

Isn't it the opposite? The complication is evidence of function. The simple code doesn't work.

	▲	kelnos 8 minutes ago \| parent [-]
		That assertion feels suspiciously like a logical fallacy.

▲

bluGill 30 minutes ago | parent | prev [-]

You can limit yourself to the performance of a 1mhz 6502 with no OS if you don't like it. Even MSDos on a 8086 with 640K ram allows for things that require complexity of this type (not spin locks, but the tricks needed to make "terminate stay resident" work are evil in a similar way)

▲

yjftsjthsd-h 25 minutes ago | parent [-]

I don't think that's fair. You can go fast, just not more than one task at a time.

	▲	bluGill 9 minutes ago \| parent [-]
		Modern CPUs (since around 2000) go faster in large part because they have multiple cores that can do more than one thing in a time. If your program needs to go faster using more cores is often your best answer and then you will need these tricks. (SIMD or the GPU are also common answers that might or might not be better for your problem)

▲ gafferongames an hour ago | parent | prev [-]

Great article! Thanks for posting this.