Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: A quota based lock Date: Thu, 11 Aug 2011 12:32:47 +0200 Lines: 87 Message-ID: <9ahpelFdfuU1@mid.individual.net> References: <83f81158-8aee-486d-a51b-c0f7dfdbb0da@h25g2000prf.googlegroups.com> <9aasp0F9v2U1@mid.individual.net> <9aeqo2F2e9U1@mid.individual.net> <9afrgkFri4U1@mid.individual.net> <517dd08b-9fea-47d4-8e7c-0098dc25e16c@k18g2000prh.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net E4J3chNUzSyw5dqD2b6tiAPQHbaEQD+73vLckqHipKz+iGShA= Cancel-Lock: sha1:1e3FBQITCO/FLev9SoBUJY98k8Q= User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 In-Reply-To: <517dd08b-9fea-47d4-8e7c-0098dc25e16c@k18g2000prh.googlegroups.com> Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:7011 On 11.08.2011 03:30, Robert Stark wrote: > On Aug 11, 3:37 am, Patricia Shanahan 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/