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

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

Re: A quota based lock

Show all headers | View raw

On 11.08.2011 03:30, Robert Stark wrote:
> 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.

I considered that as well but figured that then the starvation issue 
wouldn't be so dramatic. :-)

>> If that picture is correct, simple FIFO lock handling may be sufficient
>> to let the client requests get through fast enough.

I would have assumed that this is what Robert tried first and hit the 
starvation issue then.

>> 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?

Absolutely.  Often refactoring helps a great deal more.  Maybe there is 
a solution where an immutable fraction of the state can be shared 
reducing need for locking.  Or state can be copied and merged after 
manipulation.  There are so many options...

> 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"

Thanks for clarifying.

> Sorry i failed to make it clear in the first time.

No prob, I might actually have stumbled over my non native readerness. :-)

> I think i have to do more test using a simple FIFO lock, maybe there's
> something wrong in my code!

Please see Mark's suggestion of using fair mode as well.  You do pay a 
performance penalty for the fair mode.  Whether that is relevant in your 
case needs to be measured of course.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://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