commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [lang] New synchronization primitive
Date Sun, 06 Sep 2009 20:03:51 GMT
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


> 
> 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.mohammad@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.heger@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message