commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [lang] New synchronization primitive
Date Sun, 06 Sep 2009 16:01:23 GMT
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.

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


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 <
>> 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<> 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:
>>> For additional commands, e-mail:
>> --
>> Thanks
>> - Mohammad Nour
>> - LinkedIn:
>> ----
>> "Life is like riding a bicycle. To keep your balance you must keep moving"
>> - Albert Einstein
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message