5 ms·
The most important point is: - you cannot implement a functioning spin lock in user space (for all practical intents and purposes and if you don't resort to
by weinzierl 7y ago
The most important point is:
- you cannot implement a functioning spin lock in user space
(for all practical intents and purposes and if you don't resort to extreme measures and talking modern general purpose operating systems)
- cbsmith 7y agoDepends on what you mean by "functioning". You can make one that functions in the sense that you can lock between concurrent threads. However, it's difficult to do right and even more difficult to do in a way that is performant (and the interface to the kernel is so ill defined for this, whatever efficient solution you come up with will likely prove to be far less efficient on other systems with just subtle alterations in the underlying kernel implementation.
- lmilcin 7y agoYou 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.
- xakahnx 7y agoThis 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.
- touisteur 7y agoCan'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...).
- GhettoMaestro 7y agoObviously you've never heard of DPDK.
- kanox 7y agoReserving 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.