4 ms·
Indeed, spinlocks most definitely aren't lock-free. "rcu_read_lock" doesn't ever block (as in wait for a spinlock), right? Sometimes you just need readers to n
by vardump 10y ago
Indeed, spinlocks most definitely aren't lock-free.
"rcu_read_lock" doesn't ever block (as in wait for a spinlock), right? Sometimes you just need readers to never block and can pay higher price for other operations.
- gpderetta 10y agoI'm not very familiar with the kernel RCU, but I believe that not only rcu_read_lock does not block, it doesn't even issue any expensive memory barriers.
- webaholic 10y agoYou are right. It does not even guarantee any mutual exclusion in the read critical section i.e., the data you are reading can be changed while you are in the critical section. RCU, as the article claims, does not work in all situations.
- gpderetta 10y agoOne way to think of RCU is that it enables working with (a restricted form of) persistent data structures in languages without GC.
- amelius 10y agoFrom the article: > So as soon as a thread yields its CPU, it’s guaranteed to be out of its critical section. Therefore, the yielding can be seen as a blocking operation, meaning that readers do in fact block!
- gpderetta 10y agoyielding per-se is not a blocking operation, otherwise no algorithm would be non-blocking would under preemptive scheduling. It could be considered a potentially blocking operation if scheduling is exclusively cooperative.
- amelius 10y agoThe CPU is a resource too, for which there is contention just as for other resources such as files. Therefore, at every machine instruction, you are implictly performing a potentially blocking operation. (In a pre-emptive environment.) Unless you are in a critical section (in which your thread has exclusive control of the CPU). So the blocking may start again at the end of the section. I hope this makes it clear.
- gpderetta 10y agoAny scheduler worth anything guarantees forward progress which makes preemption very different from actual blocking.
- mtanski 10y agoOn Linux you can guarantee (with some effort) that your process / thread will be the only thing running on a core. There's a boot parameter that will let you black list CPUs on which to not schedule anything (by default). Then you use tasksel to schedule your process there as well. Finally, you can configure IRQ affinity so also doesn't handle interrupts on that core. It's not a 100% non pre-emptive but pretty close. I believe there was work being to enable it to be even more accurately 100 but I haven't followed along.