harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Gan <gan...@gmail.com>
Subject Re: Is there use case for more scalable stack, queue, deque in Harmony?
Date Thu, 26 Nov 2009 08:59:17 GMT
Tim and Jesse,

Thanks for both of you comments and happy ThanksGiving day!

We'll talk with Doug Lea to see if it's suitable to put some of our
components into JSR166 project. But notice there is a difference when
compare goal of Amino library with JSR166 project. Amino project aims to
provide really fast library, even if some functions are missing, while
JSR166 must implement a rich set of feature.   For example,
j.u.c.ConcurrentLinkedQueue will be much slower than our LockFreeQueue in
future because it needs to support remove() in the middle of queue.

And yes, ReferenceQueue is a good example that our library can be helpful to
Harmony project. That's a good example to the kind of use case that I'm
looking for inside Harmony code. I'm not trying to replace a public API, but
to increase scalability of Harmony code without hurting performance of
single threaded program. For example, if a synchronized Stack is used in
Harmony code, I'll like to try my ConcurrentStack and contribute it if the
result is good.

I'll do more grep and let you know if I found any good use case. Thanks a
lot!


On Thu, Nov 19, 2009 at 1:51 AM, Jesse Wilson <jessewilson@google.com>wrote:

> On Wed, Nov 18, 2009 at 9:43 AM, Tim Ellison <t.p.ellison@gmail.com>
> wrote:
>
> > You'd have to look a bit closer to see if these data
> > structures are used heavily,
> >
>
> Please avoid adding nonblocking behaviour where it isn't required by the
> API. Of the usages that Tim pointed out, all either don't require
> concurrency (XML, beans, Swing) or belong to java.util.concurrent, which
> isn't developed by Harmony.
>



-- 
Best Regards
James Gan
Current Project: Concurrent Building Block at
http://amino-cbbs.sourceforge.net/
Blog: http://ganzhi.blogspot.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message