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


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

Re: A quota based lock

From Robert Stark <panxiaozhong@gmail.com>
Newsgroups comp.lang.java.programmer
Subject Re: A quota based lock
Date 2011-08-10 18:30 -0700
Organization http://groups.google.com
Message-ID <517dd08b-9fea-47d4-8e7c-0098dc25e16c@k18g2000prh.googlegroups.com> (permalink)
References (7 earlier) <j1pvpg$20h$1@dont-email.me> <9aeqo2F2e9U1@mid.individual.net> <f5197447-798d-41f7-87c5-378bdba9d118@y39g2000prd.googlegroups.com> <9afrgkFri4U1@mid.individual.net> <HemdnbwH4ZBtQN_TnZ2dnUVZ_gudnZ2d@earthlink.com>

Show all headers | View raw


On Aug 11, 3:37 am, Patricia Shanahan <p...@acm.org> wrote:
> On 8/10/2011 9:55 AM, Robert Klemme wrote:
>
>
>
>
>
>
>
>
>
>
>
> > Please do not top post.
>
> > On 10.08.2011 13:40, Robert Stark wrote:
> >> 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.
>
> > This can never work: if you have jobs that - by design - hold the
> > resource for hours then no amount of lock implementation smartness will
> > prevent starvation without preemption. You cannot have a resource with
> > exclusive access, long access times and responsiveness at the same time.
> > Doing preemption manually will be difficult. It's better to break up
> > long running tasks into smaller sub tasks which need exclusive resource
> > access. Whether that's possible or not depends of course on your
> > business logic (which we still haven't seen).
>
> I interpreted the paragraph you quoted rather differently. My picture is
> that each back-end job runs for a long time, but during that time
> repeatedly acquires the contended resource, still only keeping it for
> order milliseconds at a time. I base this on "continuously acquire"
> rather than "continuously hold" the resource.
>
> If that picture is correct, simple FIFO lock handling may be sufficient
> to let the client requests get through fast enough.
>
> However, any time a lock becomes enough of an issue that it requires
> this sort of discussion, the first thing to do is to examine whether it
> can be refactored to reduce contention. Is the lock really covering only
> one resource? Can that resource be replicated? Can it be divided up?
>
> Patricia

You are right, Patricia.
"each back-end job runs for a long time, but during that time
repeatedly acquires the contended resource, still only keeping it for
order milliseconds at a time"
Sorry i failed to make it clear in the first time.
I think i have to do more test using a simple FIFO lock, maybe there's
something wrong in my code!

Back to comp.lang.java.programmer | Previous | NextPrevious 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