Hacker News new | past | comments | ask | show | jobs | submit login

Hard fairness guarantees for locking are very expensive and only situationally needful, so it's hard to justify paying a high cost to have them always on. It seems like the best thing to do is to use the fastest locking primitive you can find, and implement fairness on top of that in the rare case that you need it.



Eventual fairness costs nothing.


Right, I'm referring to the idea of immediate fairness. I'm agreeing w/ your approach.


Might you have any good resources about hard fairness vs eventual fairness locking?


It's all in the commit.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: