Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #6989
| Date | 2011-08-10 12:37 -0700 |
|---|---|
| From | Patricia Shanahan <pats@acm.org> |
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: A quota based lock |
| References | (6 earlier) <9aasp0F9v2U1@mid.individual.net> <j1pvpg$20h$1@dont-email.me> <9aeqo2F2e9U1@mid.individual.net> <f5197447-798d-41f7-87c5-378bdba9d118@y39g2000prd.googlegroups.com> <9afrgkFri4U1@mid.individual.net> |
| Message-ID | <HemdnbwH4ZBtQN_TnZ2dnUVZ_gudnZ2d@earthlink.com> (permalink) |
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
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar
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