News for hackers. Stuff that matters.

A comment on No nuances, just buggy code (was: related to Spinlock implementation). Parent comment

Re:No nuances, just buggy code (was: related to Spinlock imp... by lmilcin on Sunday January 05, 2020 @11:15AM (#21961899)
You can, but it requires special architecture for the application. The cpuset can be used to disable scheduler use of the core and then you can pin application threads to cores, single thread per core.

Only then it makes sense tu use spin locks.

[ Parent | on HN ]
Re:No nuances, just buggy code (was: related to Spinlock imp... by kanox on Sunday January 05, 2020 @03:32PM (#21963842)
Reserving CPUs for your application definitely qualifies as "extreme measures".

In general you should expect userspace code to be scheduled out at any time and use locking primitives that the kernel knows about.

[ Parent | on HN ]
Re:No nuances, just buggy code (was: related to Spinlock imp... by xakahnx on Sunday January 05, 2020 @11:29AM (#21961988)
This is still a disaster with hyperthreading where you can have two threads contending for a lock on the same physical core.

Even if your thread won't be scheduled off the core I don't know if you might still have irqs stealing time during the critical section.

[ Parent | on HN ]
Re:No nuances, just buggy code (was: related to Spinlock imp... by touisteur on Sunday January 05, 2020 @11:51AM (#21962144)
Can't you isolate cores from irqs with irq affinities? I'd be more worried by SMM stealing CPU time (ugh... talk about sad stories of 'real-time' Linux...).
[ Parent | on HN ]