5 ms·
summary: Don't roll your own (spin) locking unless you really want to go down the rabbit hole. Linus thinks locking is a PITA and there be dragons. You have bee
by sfgweilr4f 7y ago
summary: Don't roll your own (spin) locking unless you really want to go down the rabbit hole. Linus thinks locking is a PITA and there be dragons. You have been warned.
- AYBABTME 7y ago_spin_ locking in particular
- PudgePacket 7y agoThey mention all locking > But don't write your own. Find somebody else that wrote one, and spent the decades actually tuning it and making it work. > Because you should never ever think that you're clever enough to write your own locking routines.. Because the likelihood is that you aren't (and by that "you" I very much include myself - we've tweaked all the in-kernel locking over decades, and gone through the simple test-and-set to ticket locks to cacheline-efficient queuing locks, and even people who know what they are doing tend to get it wrong several times). > There's a reason why you can find decades of academic papers on locking. Really. It's hard.
- taneq 7y agoSynchronization primitives are another thing along with dates and names and postcodes and unicode text editing: "Stuff you should avoid writing yourself if at all possible because they are incredibly fiddly to get absolutely right."
- hermitdev 7y agoAdd to that lock-free concurrent data structures.
- sfgweilr4f 7y agoThey all share that quality of "its straightforward, anyone can just look up the details and make it"... a month later you're still chasing some detail as some bureaucrat has added some new wrinkle. Now a rule change elsewhere has happened... it never ends. Plus each locality has its own history and the details all make sense for them but not necessarily for you and your codebase. Simple to implement but the complexity is getting it right for every case. None of it is easy.
- skunkworker 7y agoAlso add crypto algorithms to that. I know of too many people that thought, a SHA-512 is fine for passwords. /facepalm
- shandor 7y agoLike all the mainstream Linux distributions out there? But seriously, IIRC they do 5000 rounds by default, but I've been wondering for a few years how is it that supporting nothing better than SHA512 for the whole /etc/shadow -based system is still ok? How come there's still no support for scrypt or bcrypt?
- tialaramex 7y agoBecause it actually hardly matters at all? It's salted enough that it's not amenable to a time-space optimisation and it's pessimised enough to make trivial attacks impractical so bad guys who have the database will resort to brute force on individual passwords. At which point either you have a good password and they can't guess it or you don't. Fancier schemes are about the margin, can we make it too expensive to brute force say 8 alphanumerics? But you don't need to live in the margins and you shouldn't.
- imtringued 7y agoI don't understand this complaint. Cryptographic hashing gets obsoleted all the time. No matter which algorithm you choose you're just buying time until a better algorithm is needed. One day we will facepalm because people didn't use quantum resistant algorithms.
- colatkinson 7y agoA straight hashing algorithm isn't what you want for storing passwords. At a minimum, you want it salted. It's also advisable to include an iteration count so that (a) brute-forcing is harder, and (b) you can tweak just one parameter in the future to deal with hardware speed increases. At this point, you've just reinvented a KDF and should use PBKDF2, scrypt, or whatever the KDF du jour is. TL;DR storing passwords with SHA512 is bad, storing them with PBKDF2-SHA512 is ok and likely overkill.
- saalweachter 7y agoYou're also much, much better off figuring out how to structure your many threads so they interact as little as possible than trying to make them interact quickly, performance-wise.