Re: A new queue has come

Quartz wrote:
> The queue must be synchronized at some point to maintain the queueSize value, for predicates that
> need it. And if the queue is fully concurrent including its size, like in jdk 
1.5, that is because
> .size() is not a getter but the whole very long traversal to figure the size. At this point, it
> penalises the predicate and enqueuing will suffer dramatically. Otherwise, readers and writers
> update the queueSize variable and they must be entering a synchronized critical zone. Su much for
> concurrency.

My DynamicArrayBlockingQueue should be very effecient in situation 
without a lot of contention.  But I think that other kind of queue, like 
a LinkedBlockingQueue, could be more scalable (I will try to prove it 
soon).  These two king of queue are complementary.

So, we could create a mecanism where Sandstorm detect dynamically the 
queue contention and change on the fly the queue implementation to 
improve performance.  (Sandstorm will do this operation only rarely)

To achieve that, handlers could simply have a queue proxy instead of the 
real queue.  Handlers will not be aware that Sandstorm is changing the 
queue implementation.


> Meanwhile, I found months ago that the biggest cost in the queue logic is the 'new
> QueueElementIF[qs]' of dequeue_all or dequeue(n). This new array is trashing memory, but unless
> there is a very explicit (but sadly, non-enforcable) contract with handlers, this array must be
> given to handler. If handlers were not allowed to keep the array for them, then the dequeue could
> cache some array instances. A step further would be
>      handler.handleEvents(array, offset, len).
> Looks ugly, but hell, this is sandstorm!

I have already thinking about that.  Why don't create methods 
QueueIF.dequeue_all(List list) and EventHandlerIF.handleEvents(List 
list).  We could specify in the EventHandlerIF specification that this 
list cannot be cached by user.  Like this, we could reuse our list 
(ArrayList) and don't create QueueElementIF array all the time.  Seem a 
good idea.

Jean




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/