Phil Steitz schrieb:
Oliver Heger wrote:
AIUI the mission of commons-lang is to provide extensions and
improvements for existing Java API classes. The concurrent package in
Java 5 is a great step forward in supporting multi-threaded programming
in Java, nevertheless there is certainly still room for improvements.
The proposed concurrent utilities for lang are not intended to reinvent
the wheel, but to implement additional and convenience functionality on
top of the existing API.
+1
@Ted: The proposed class is not high-sophisticated, but given the
additional timing aspect it is not trivial either. Of course, it can be
implemented using standard Java means (that's what I did), but having
something that works out of the box is surely preferable than having to
create your own implementation. This is the purpose of a library, isn't it?
Agree on characterization of [lang]. I wonder though whether what
you have in mind might quickly grow to be too large for [lang]. How
about starting in the sandbox (once you have the grant) so we have
something concrete to talk about? Looks useful and interesting to me.
Phil
The sandbox would be an option, but I don't know whether these
suggestions really become too large for [lang].
When we talked about a new version of [lang] that would be compatible
with JDK 1.5 I made the proposal for some utilities related to
multi-threading. Since then I have added some JIRA tickets for this
topic, namely LANG-496, LANG-499, and LANG-501. IMHO this is comparable
in amount and intension to the text package already existing in [lang].
Maybe an active [lang] committer can comment on this?
Oliver
Oliver
Ted Dunning schrieb:
In particular, why can this not be implemented using the Java 5
primitives?
For instance, a thread could be created that adds tokens at a fixed
rate to
a blocking queue up to a small maximum. Threads wishing to consume
the load
bounded resource would request a token before sending a query. This
would
enforce a maximum use rate.
I could imagine a similar use of a semaphore as well.
On Sat, Sep 5, 2009 at 3:03 PM, Mohammad Nour El-Din <
nour.moham...@gmail.com> wrote:
Sorry for the question, but why we need a new *concurrent* utils in
commons-lang while we have the concurrent package in Java SE 5 ?
On Sat, Sep 5, 2009 at 9:48 PM, Oliver
Heger<oliver.he...@oliver-heger.de> wrote:
In my day job I have written a synchronization primitive that may be of
interest for the proposed concurrent package of the new version of
commons-lang. I first want to check whether there is interest in this
stuff,
then I can talk to my employer about the code donation (which hopefully
should not be a problem).
Now to the synchronization primitive: It is a class called
"LoadBarrier"
that is somewhat similar to a semaphor in that it allows a configurable
number of locks to be hold. But there is also a timing aspect: The
limit
of
locks is enforced in a configurable time unit. If a thread requests
another
lock when the maximum number of locks is already reached, it gets
blocked
until the time unit is over. After that all blocked threads are
freed and
can again try to aquire a lock.
The background of this class is that it provides an easy way of
controlling
the load produced by a process or enforcing a threashold. In our use
case
we
had a background process running queries on a database for statistical
evaluations. To ensure that the database load does not affect the
system
a
LoadBarrier was used that enforced a limit of database queries per
second.
WDYT? If there is interest, I am going to address my employer and then
create a JIRA enhancement ticket.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
--
Thanks
- Mohammad Nour
- LinkedIn: http://www.linkedin.com/in/mnour
----
"Life is like riding a bicycle. To keep your balance you must keep
moving"
- Albert Einstein
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
