5 ms·
Be careful with spin locks. We used to have one in the ZeroTier core. We pulled it due to a crazy insane bug where it would hang on single core machines and ano
by api 5y ago
Be careful with spin locks. We used to have one in the ZeroTier core. We pulled it due to a crazy insane bug where it would hang on single core machines and another one where it would run away on CPU usage on massively multicore machines. These bugs had the same cause. Think about it.
Don't use spin locks unless you have profiled and have a clear understanding of the contention factors involved. Also be sure to test on single core and massively multicore.
Also look at whether you can use atomics. Atomics are better than lock guarded things in almost every way. The only time locks beat atomics is when you are updating a bunch of things in which case it may be faster to lock once than to update 10 atomic variables.
Message passing can also win sometimes over concurrent access even if it involves more copying. Profile and think.
- PaulDavisThe1st 5y ago> The only time locks beat atomics is when you are updating a bunch of things in which case it may be faster to lock once than to update 10 atomic variables. Locks are mandatory when you're updating data that does not fit into a single atomic type. You cannot use N atomics to create atomic update of a data structure that must be semantically atomic across its N members.
- gpderetta 5y agoTechnically any algorithm can be implemented in a lock free way and there are n-way CAS constructs that indeed allow updating N memory locations atomically. In practice they are very slow.
- atq2119 5y agoYou can use RCU to do this, but I'd argue that everything else ends up being more or less a lock by another name (maybe you could do read/write where the read is optimistic, but at least the write side will have some sort of lock). I'm curious what you had in mind?
- deleted 5y ago[deleted]
- gpderetta 5y agoI misplaced my copy of The Art Of Multiprocessor Programming with the details, but with a simple CAS primitive you can build a general N-CAS algorithm and from that implement any algorithm ina a truly wait free way. It will be slow and won't scale, but will indeed be wait free
- PaulDavisThe1st 5y agoMost RCU requires a lock, if only to handle cleaning up the "dead wood" that occurs on every update (write).
- MaxGanzII 5y agoLock-free garbage collection exists and there's quite a body of literature.
- PaulDavisThe1st 5y agoYeah, I've read a lot of it. It all comes with caveats and potential performance issues.
- MaxGanzII 5y agoSeemed okay to me with regard to caveats. Performance issues -> it's lock-free and scales profoundly better than non-lock-free.
- PaulDavisThe1st 5y agoYou can do this sort of thing with write-ordering a "generation counter" that is updated before and after writing a bunch of other data elements. The problem is that it makes the read slow - you have to use a CAS-style loop even to read anything (you must check that the generation counter has the same value before and after reading the other data). It also adds more memory barriers than a simple lock.
- api 5y agoSure, forgot to mention that, but that's only if it must be semantically atomic. That's not always the case.
- MaxGanzII 5y agoYou can produce this behaviour. Look for MCAS, from Cambridge Uni. It never took off. I think it didn't scale.
- kqr 5y agoOr as Torvalds said, don't use spinlocks in user space. https://www.realworldtech.com/forum/?threadid=189711&curpostid=189723 https://www.realworldtech.com/forum/?threadid=189711&curpost...