Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: A quota based lock Date: Wed, 10 Aug 2011 09:36:33 +0200 Lines: 56 Message-ID: <9aeqo2F2e9U1@mid.individual.net> 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 X-Trace: individual.net Mnp2CcPxi1vEfRpdtEolLgv3HJmX+ZPZosHJwYUKMy6uX2V+g= Cancel-Lock: sha1:n3kXvLQ+F0aJysIAH9w9MpZzZqk= User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6956 On 09.08.2011 02:41, Eric Sosman wrote: > 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. Absolutely agree. And we still need the OP to state his problem / requirements clearly. Robert, what is it that you really need? What is your use case and your ultimate goal? Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/