The difference is when there's contention. A spinlock will burn CPU cycles but a mutex will yield to another thread or process (with some context switch overhead).
A spinlock should only be used when you know you're going to get it in the next microsecond or so. Or in kernel space when you don't have other options (e.g. interrupt handler). Anything else is just burning CPU cycles for nothing.
Mutex and condition variables (emphasis on the latter) are much more useful than spinlocks and atomics for general multithreaded programming.
Outside of hard realtime code, there's zero reason to use spin locks.
Interesting read: http://www2.rdrop.com/~paulmck/realtime/SMPembedded.2006.10....
That is just not true. You _must_ use them in the case where the kernel is non-preemptable. Additionally, if the locked resource is held for a very short time, a spin lock is likely a more efficient choice than a traditional mutex.
On some common architectures, releasing a spin lock is cheaper than releasing a mutex.
But if you don’t have a guarantee the lock owner won’t be preempted, well, spinning for a whole timeslot is quite a bit more expensive…
 you better be careful with spinlocks and priorities here as you can livelock forever.
That said I'm used to situations where we're pinning thread affinity to specific cores and really trying to squeeze out what you can from fixed resources.
Setting CPU affinity will ensure that you always get the same core, but it might not increase performance and could adversely affect other parts of the system.
CPU affinity is a good fit for continuously running things like audio processing or game physics or similar. It's not good when threads are blocked or react to external events.
In most cases it's just unnecessary because the kernel is pretty good in keeping threads on cores anyway.