Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

siliceum.com

Post reply on HN
Print view View original

41–50 of 66 posts

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

#41

Post by Lectem »

rdtsc wrote: post #25

> Notice that in the Skylake Client microarchitecture the RDTSC instruction counts at the machine’s guaranteed P1 frequency independently of the current processor clock (see the INVARIANT TSC property), and therefore, when running in Intel® Turbo-Boost-enabled mode, the delay will remain constant, but the number of instructions that could have been executed will change. rdtsc may execute out of order, so sometimes an…

The issue with that is that a load fence may be very detrimental to perf. It doesn't really matter if rdtsc executes out of order in this code anyway, and there is no need for sync between cores.

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

#42

Post by Lectem »

horizion2025 wrote: post #31

My concurrency knowledge is a bit rusty but aren't spinlocks only supposed to be used for very brief waits like in the hundreds of cycles (or situations where you can't block... like internal o/s scheduling structures in SMP setups)? If so how much does all this back off and starvation of higher priority threads even matter? If it is longer then you should use a locking primitive (except for in those low level os str…

That's how they are supposed to work indeed! But spin locks aren't the only spin loops you may find, and allocator for example do spin. And for example under an allocation heavy code (that you should avoid too, but happens due to 3rd parties in real life), this can trigger contention, so you need contention to not be the worse type of contention.

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

#43

Post by spacechild1 »

Lectem wrote: post #39
spacechild1 wrote: post #29

Nice article! Yes, using spinlocks in normal userspace applications is not recommended. One area where I found spinlocks to be useful is in multithreaded audio applications. Audio threads are not supposed to be preempted by other user space threads because otherwise they may not complete in time, leading to audio glitches. The threads have a very high priority (or have a special scheduling policy) and may be pinned t…

I've heard of issues on Arm devices with properly isolated cores (only one thread allowed, interrupts disabled) because the would interact with other threads using such a spinlock, threads which were not themselves isolated. The team replaced it all with a futex and it ended up working better in the end. Sadly this happened while I was under another project so I don't have the details, but this can be problematic in…

For task queues we would use a lockfree queue, wake up the threads once at the beginning of the audio callback and then spin while waiting for tasks, just as you described.

My example above was rather about the DSP graphs themselves that are computed in parallel. These require to access to shared resources like audio buffers, but under no circumstance should they give up their timeslice and yield back to the scheduler. That's why we're using reader-writer spinlocks to synchronize access to these resources. I really don't see any other practical alternative... Any ideas?

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

#44

Post by lmm »

CamperBob2 wrote: post #3

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

Probably not, not without formal verification which is usually lacking.

Everyone's computers hang or get slow some of the time. Probably all of our locks have bugs in them, but good luck getting to the bottom of that, right now the industry is barely capable of picking a sorting algorithm that actually works.

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

#45

Post by m-schuetz »

spacechild1 wrote: post #29

Nice article! Yes, using spinlocks in normal userspace applications is not recommended. One area where I found spinlocks to be useful is in multithreaded audio applications. Audio threads are not supposed to be preempted by other user space threads because otherwise they may not complete in time, leading to audio glitches. The threads have a very high priority (or have a special scheduling policy) and may be pinned t…

Recently implemented a fixed-size memory pool with spinlocks and now I'm wondering - how would one implement them without a spinlock?

Edit: Maybe I'm confusing terminology. What I'm doing is looping until other threads returned memory, but I'm also doing a short sleep during each loop iteration.

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

#46

Post by Lectem »

m-schuetz wrote: post #45
spacechild1 wrote: post #29

Nice article! Yes, using spinlocks in normal userspace applications is not recommended. One area where I found spinlocks to be useful is in multithreaded audio applications. Audio threads are not supposed to be preempted by other user space threads because otherwise they may not complete in time, leading to audio glitches. The threads have a very high priority (or have a special scheduling policy) and may be pinned t…

Recently implemented a fixed-size memory pool with spinlocks and now I'm wondering - how would one implement them without a spinlock? Edit: Maybe I'm confusing terminology. What I'm doing is looping until other threads returned memory, but I'm also doing a short sleep during each loop iteration.

That's a spin loop ;)

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

#47

Post by Lectem »

spacechild1 wrote: post #43
Lectem wrote: post #39

Earlier quoted context omitted.

I've heard of issues on Arm devices with properly isolated cores (only one thread allowed, interrupts disabled) because the would interact with other threads using such a spinlock, threads which were not themselves isolated. The team replaced it all with a futex and it ended up working better in the end. Sadly this happened while I was under another project so I don't have the details, but this can be problematic in…

For task queues we would use a lockfree queue, wake up the threads once at the beginning of the audio callback and then spin while waiting for tasks, just as you described. My example above was rather about the DSP graphs themselves that are computed in parallel. These require to access to shared resources like audio buffers, but under no circumstance should they give up their timeslice and yield back to the schedule…

I suppose you need to be able to read data from the buffers to know what parts of the graph to cull? Is computing the graph really long or the graph needs update mid execution? If you really have nothing else to do on those threads/cores, spinning might actually be the solution(considering a high sampling rate). I'd still fallback to the OS after a certain amount of time, as it would mean you failed to meet the deadline anyway. I would also reduce as much as possible the need for writes to synchronized resources where possible, so that you can just read values knowing no writes can happen during your multiple reads.

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

#48

Post by kobebrookskC3 »

fsckboy wrote: post #32

what is/are the thread synchronization protocol called which is the equivalent to ethernet's CSMA? there's no "carrier sensing", but instead "who won or mistakes were made" sensing. or is that just considered a form of spinlock? (you're not waiting for a lock, you perform your operation then see if it worked; though you could make the operation be "acquire lock" in which case it's a spinlock)

isn't that more like optimistic concurrency control?

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

#49

Post by m-schuetz »

Lectem wrote: post #46
m-schuetz wrote: post #45

Earlier quoted context omitted.

Recently implemented a fixed-size memory pool with spinlocks and now I'm wondering - how would one implement them without a spinlock? Edit: Maybe I'm confusing terminology. What I'm doing is looping until other threads returned memory, but I'm also doing a short sleep during each loop iteration.

That's a spin loop ;)

I see, thanks.

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

#50

Post by pjmlp »

bluGill wrote: post #13
yjftsjthsd-h wrote: post #12

Earlier quoted context omitted.

Modern CPUs can do 4-5 GHz singled threaded. (Sometimes you can even get a higher clock speed by disabling other cores.) This somewhat outpaces "a 1mhz 6502" even without parallelization.

They can, but nobody runs a single process on such CPUs. They run some form of OS which implements spinlock, mutexes, and all these other complex things. I suppose someplace someone is running an embedded system without an OS on such a processor - but I'd expect they are still using extra cores and so have all of the above tricks someplace.

I never get the single threaded assertions regarding CPU performance, it is mostly useless in the day of premptive scheduling in modern OSes.

Yes it matters on MS-DOS like OS design, like some embedded deployments and that is about it.

It is even impossible to guarantee a process doesn't get rescheduled into another CPU with the performance impact it entails, unless the process explicitly sets its CPU affinity.

Post reply on HN