2

I'm using spinlocks (pthread ones) with generally O(1) list element access/removal in the locked code section.

I say generally because on 99.9% of cases the code doesn't loop through the list (which might contain 1000+ elements).
The code will usually extract one only element based on a list element hint pointer and then perform a couple of if branches to modify the cited hint element; still it should be a non contiguous access to memory.

Is it a good idea to use spinlocks or should I move to mutexes?

I'm aiming at max performance, don't care about CPU (over) usage in this context.

Cheers

Emanuele
  • 1,408
  • 1
  • 15
  • 39
  • 10
    Benchmark. I don't think anyone can answer this for you with the details you give. – Mat Feb 23 '13 at 10:40
  • what do you mean performance? i thought cpu usage is performance... – thang Feb 23 '13 at 10:41
  • 1
    @thang: No, with a spinlock, CPU usage can be just heating up the room. – thejh Feb 23 '13 at 10:41
  • huh? performance can mean many things. the question is what do you mean when you want max performance... – thang Feb 23 '13 at 10:43
  • You use a spin lock where the tasks are lightweight, so that a context swapping is more expensive than an active waiting. – Ramy Al Zuhouri Feb 23 '13 at 10:48
  • 5
    Definitely compare with a normal pthread mutex. The normal mutex already does an intelligent amount of spinning before resorting to a system call, and I imagine you'd be hard-pressed to come up with a cleverer strategy yourself. – Kerrek SB Feb 23 '13 at 10:51
  • @Emanuele What performance parameter are you looking for? Throughput? If it's throughput you are optimizing for, you should optimizie the time the object is locked. The information "O(1)" only tells us that your task is completed in constant time. There is no information if your task completes "fast". So the more important question before every other question is WHAT you are locking not how you are locking. – junix Feb 23 '13 at 11:06
  • @KerrekSB I don't think mutex lock does any busy-spinning, at least with `pthreads` in `glibc`. – Maxim Egorushkin Feb 23 '13 at 11:22
  • I believe it all boils down to how long I'm going to keep the lock eventually, right? Cheers – Emanuele Feb 23 '13 at 22:15

2 Answers2

0

Generally, for short critical sections (like where it just updates list pointers) spin lock may be preferred.

With little contention there should be little difference between spin locks and mutexes because the non-contended path is heavily optimized in the latter.

The difference comes when a critical section becomes contended. When the mutex is taken, locking it blocks the thread and takes it off the scheduler run queue taking it much longer to wake up and lock the mutex when it is eventually released, whereas a spin lock would just spin in the hope that the spin lock is released shortly.

psmears
  • 26,070
  • 4
  • 40
  • 48
Maxim Egorushkin
  • 131,725
  • 17
  • 180
  • 271
0

After doing some benchmarks with reproducible test cases, switching between pthread mutex and spinlock implementation, I can say the if mutex uses a bit less CPU, the spinlock implementation is twice as fast in processing the elements off the queue.

I believe the correct answer, given the O(1) nature of the function processing the list and the fact this (mostly) constant time is tiny, favours the spinlock choice vs. mutex.

So if one wants to achieve max performance, doesn't care about CPU wasted cycles, spinlocks are preferable vs mutexes in case the protected code execution time is tiny (and better constant).

Emanuele
  • 1,408
  • 1
  • 15
  • 39