Re: A quota based lock
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/