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


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

Re: A quota based lock

From Robert Klemme <shortcutter@googlemail.com>
Newsgroups comp.lang.java.programmer
Subject Re: A quota based lock
Date 2011-08-10 18:55 +0200
Message-ID <9afrgkFri4U1@mid.individual.net> (permalink)
References (5 earlier) <j1pbj1$hvd$1@dont-email.me> <9aasp0F9v2U1@mid.individual.net> <j1pvpg$20h$1@dont-email.me> <9aeqo2F2e9U1@mid.individual.net> <f5197447-798d-41f7-87c5-378bdba9d118@y39g2000prd.googlegroups.com>

Show all headers | View raw


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 want to complete it and test how it goes.

Good idea.

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

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