hit reply too soon. editing

---------- Post updated at 02:53 PM ---------- Previous update was at 02:35 PM ----------

Don't panic. 'lock' is not a mutex. A single memory bus always works like its "single-threaded" just because it's physically impossible for it to do anything else.

Imagine two threads running XCHG in an infinite loop. This is what the order they're let access memory might end up as.

Since this isn't LOCK XCHG, this operation isn't guaranteed to be atomic. Writes might happen interleaved like this, or in any order.

Now, with LOCK XCHG:
The same amount of waiting is happening, LOCK just forces an atomic order.

memory, or cache. In recent x86 systems, cores can update each others' cache; that's what Hypertransport's for, a shortcut between caches. Excellent. And when they run out of jobs completely? Your readers would spend a lot of time scanning a mostly-empty list, and your writer would spend a lot of time scanning a mostly-full one. That's a lot of time wasted. You'd be much better off just using a normal one-writer-many-reader queue. It won't block when there's lots of work, and will actually put threads to sleep when there's none, instead of everything spinlocking forever. Using spinlocks to handle a work queue, now that's overkill.