Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #6969

Re: A quota based lock

Show all headers | View raw

Sorry, i use google groups and i could not find my post until today.
Thank you all!
 There is a single resource and i want more sophisticated control over
it, there're different types of jobs( client requests, back-end jobs)
running in my system, every job would hold the resource for 1ms~20ms,
some back-end jobs will run for several hours and they will
continuously acquire this resource, in this case, client requests will
suffered low throughput even starvation, so i come up with this idea,
and i do want to keep it as simple as possible. Client request may
come once a while (10-50 per second), acquire lock 1-2 times and exit.

I keep a queue for each type of job, and keep counters to make
schedule decision, the counters expired when their sum exceed 100 or
some jobs' counter exceed their quota and no other jobs pending. But i
still introduce an extra dispatch thread, i find it extremely hard to
write something like Tom Anderson said ...
I want to complete it and test how it goes.

On Aug 10, 3:36 pm, Robert Klemme <shortcut...@googlemail.com> wrote:
> 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 endhttp://blog.rubybestpractices.com/

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

A quota based lock Robert Stark <panxiaozhong@gmail.com> - 2011-08-08 00:13 -0700
  Re: A quota based lock Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-08-08 07:58 -0400
    Re: A quota based lock Knute Johnson <september@knutejohnson.com> - 2011-08-08 09:48 -0700
      Re: A quota based lock markspace <-@.> - 2011-08-08 10:00 -0700
        Re: A quota based lock Knute Johnson <september@knutejohnson.com> - 2011-08-08 11:39 -0700
          Re: A quota based lock markspace <-@.> - 2011-08-08 11:57 -0700
            Re: A quota based lock Robert Klemme <shortcutter@googlemail.com> - 2011-08-08 21:46 +0200
              Re: A quota based lock Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-08-08 20:41 -0400
                Re: A quota based lock Robert Klemme <shortcutter@googlemail.com> - 2011-08-10 09:36 +0200
                Re: A quota based lock Robert Stark <panxiaozhong@gmail.com> - 2011-08-10 04:40 -0700
                Re: A quota based lock Robert Klemme <shortcutter@googlemail.com> - 2011-08-10 18:55 +0200
                Re: A quota based lock Martin Gregorie <martin@address-in-sig.invalid> - 2011-08-10 19:26 +0000
                Re: A quota based lock Patricia Shanahan <pats@acm.org> - 2011-08-10 12:37 -0700
                Re: A quota based lock Robert Stark <panxiaozhong@gmail.com> - 2011-08-10 18:30 -0700
                Re: A quota based lock markspace <-@.> - 2011-08-10 19:17 -0700
                Re: A quota based lock Robert Klemme <shortcutter@googlemail.com> - 2011-08-11 12:32 +0200
          Re: A quota based lock Tom Anderson <twic@urchin.earth.li> - 2011-08-09 21:00 +0100
  Re: A quota based lock markspace <-@.> - 2011-08-08 07:58 -0700
  Re: A quota based lock Tom Anderson <twic@urchin.earth.li> - 2011-08-09 21:45 +0100

csiph-web