| |||||||||||||
Improving ticket spinlocksImproving ticket spinlocksPosted Jan 4, 2013 4:08 UTC (Fri) by jdike (subscriber, #4055)Parent article: Improving ticket spinlocks
> The goal is to have a CPU query the lock an average of 2.7 times before
> obtaining it. The number 2.7, once again, was obtained by running lots of > tests and seeing what worked best
This is e, which shows up in similar contexts. I have a fuzzy recollection that in a situation where you want to buy something, i.e. a house or car, you know nothing about the market going in, and you need to decide to buy or not on the spot (i.e. the item disappears from the market after you've seen it), you need to sample the market (i.e. look without buying) before thinking about buying. The optimal number of items to sample is e, which translates to 3 for discrete things like houses and cars.
(Log in to post comments)
Improving ticket spinlocks Posted Jan 5, 2013 3:27 UTC (Sat) by spigot (subscriber, #50709) [Link] It sounds like you're describing the secretary problem. The idea is that you have n applicants for a job, each of whom has a rank from 1 (most qualified) to n (least qualified). You get to interview them in a random order, and after each interview you must decide, on the spot, whether to hire them or reject them. You would like a procedure to maximize your chances of hiring the most qualified candidate. It turns out that you should reject the first n/e candidates, then hire the first of the remainder who is more qualified than any of the rejects (or hiring the last, if none are more qualified). However, it's not obvious to me that this is applicable to the problem at hand.
|
|||||||||||||