Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: A quota based lock Date: Mon, 08 Aug 2011 20:41:46 -0400 Organization: A noiseless patient Spider Lines: 45 Message-ID: References: <83f81158-8aee-486d-a51b-c0f7dfdbb0da@h25g2000prf.googlegroups.com> <9aasp0F9v2U1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 9 Aug 2011 00:42:24 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="f8igmItKsWs6nM5YanFxAA"; logging-data="2065"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+utnHKasT2Z72EXUL61w+g" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 In-Reply-To: <9aasp0F9v2U1@mid.individual.net> Cancel-Lock: sha1:A2WmUKECmg+R5GdfTs7vdrsconc= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6887 On 8/8/2011 3:46 PM, Robert Klemme wrote: > On 08.08.2011 20:57, markspace wrote: >> On 8/8/2011 11:39 AM, Knute Johnson wrote: >> >>> No priority scheme will ever be truly fair. I'll bet you could get >>> pretty close without being too complicated. I'll think about it some >>> more. >> >> >> A simple priority system might involve multiple queues, where the high >> priority queues are serviced X times more than the lower ones. >> >> E.g., two queues. Queue A gets 10 jobs executed for each 1 job that >> queue B gets executed. But because queue B is always guaranteed to be >> serviced eventually, there is no starvation. >> >> This is a simple step up from round-robin service (which is what Eric >> proposed). There are many algorithms existing. Check out any text on OSs >> and job scheduling. > > Another idea would be to take the time a task has access to the > resource, sum up per task category and for the next task pick the first > one from the category which is furthest below its specified share > (percentage). Basically your approach measures executions and this > approach measures actual resource usage time. Yes, all these disciplines are plausible. My main piece of advice is KISS: Begin with the simplest possible solution, and elaborate it only when there's solid evidence it won't suffice. Sometimes the evidence can be gathered in advance: If you know things about arrival rates and hold times and latency requirements, you may be able to do a calculation that shows simple FIFO won't hack it. More often, given the inherent complexity and "brittleness" of software systems, you'll need to implement first and measure afterwards to learn about a solution's shortcomings. This can lead to discarding the first solution -- but, hey: It was the simplest one you could imagine, so you probably didn't expend inordinate effort on it, right? Much cheaper to jettison a simple approach than a complicated one. KISS. -- Eric Sosman esosman@ieee-dot-org.invalid