commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: Clearing the air regarding Avalon utilities and Commons
Date Wed, 26 Dec 2001 20:22:34 GMT
Scott Sanders wrote:

>>>So then you start moving it over.  In commons everything is 
>>broken out
>>>component-wise, but this is nothing new.  Let's start 
>>talking about how
>>>to go forward with whatever you/we feel should be in the 
>>commons.  I see
>>>commons as a bunch of components, but I tend to NOT see a 
>>framework in
>>>So let's get all Excalibur's and Avalon's utility code into commons,
>>>then Excalibur still uses it, and commons doesn't have to rewrite
>>>(although rewriting seems to be the jakarta way, IMHO).  Everybody
>>>should win.  Right?  
>>Now Avalon utilities include a pooling implementation that is 
>>nothing like
>>the Pool package in Commons.  Should the new pooling package 
>>be moved in
>>with that?  And then what about the synchronization 
>>primitives?  Do we know
>>where they would go?
> What makes the Excalibur pool different/better?  We start talking about
> it to see what to do:
>   - Can we condense/refactor to just one?
>   - Do we need both?
>   - Is one better/more useful than the other?

The pooling ideas are different.  I am beginning to experiment with
managed pools that perform sizing information in a separate thread.
The experimentation happens in Excalibur's Scratchpad, not in the
released jar.

There are many things to discuss.

> We just need to start talking about it :)  
> All of this is just an email thread away ;-)

Ok, let me talk with the Avalon committers, to see about doing this.

> IMHO the synch primitives would go with the threading proposal in the
> sandbox.  Do your primitives look like these?  How are they different?

Actually, what is in the Threading project is mostly queue classes...
something that I am working on and have a very cool implementation of.
(I.e. how about transactional enqueuing, etc.).

There is a Semaphore and Mutex object in the commons project, but no
DijkstraSemaphore (we have both), ReadWriteLock, ThreadBarrier, or
Sync interface.

The Excalibur event package has the queue classes and implementations.
The Queues have been tested threadsafe and can perform a complete enqueue/
dequeue pair in a few nanoseconds (based on average of 11 million
enqueue/dequeue ops).  Further, the Queues have transactional enqueuing
capabilities that work like this:

PreparedEnqueue stack = queue.prepareEnqueue( elements ); // elements is an array
                                                           // of QueueElement objects

if ( condition == ok )

There is more, but that is one point of distinction

> I am actually excited about commons and Avalon/Excalibur working more
> closely to each other.  Sam came in with Gump and managed to get the
> APIs to stabilize, now we need another level of cooperation.  I think
> that this can make it happen.  

I would like to see this happen, but am feeling this out step by step.

> As an aside, I have now read the "Developing with Avalon" paper and I
> must say that is the best description of a framework that I have ever
> read.  Excellent work!

Thank you.  All I did was summarize a year and a half of email conversations...
Not that easy, but in the long run, it helped out many people including
my company :)


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

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

View raw message