[concurrency-interest] Conja-- an accidental jsr166y alternative

Paulo Levi i30817 at gmail.com
Thu Nov 19 01:38:06 EST 2009


You have cool ideas.
I "made" (copied most of the concepts) these (terrible) classes for
scheduling/composing Callables. One of the situations i've found is exactly
the one you describe in the profileration of executors example you give,
however i needed to have the requirement that the subtask was only run once
at a time (huuuuuge memory sink). So i composed my composable callables
(terrible outdated name it has now) and sent it to a 1 thread executor just
for that subtask. How would your library handle things like that?

How about scheduling problems? (i'm having that too - one of my task runs
the subtask with the huuuuuugee memory requirement, in a LIFO order (with a
executor from Threads there, however another task - that doesn't know
anything about the first - also runs a slightly different version of the
same task/function -> things explode).
I don't see how could you keep the different Priorities consistent in the
same Executor (all those task + some that i might execute later should run
LIFO or FIFO and another should run as soon as possible) or other out there
combinations.

http://code.google.com/p/bookjar-utils/source/browse/BookJar-utils/src/util/ChainRunnable.java
http://code.google.com/p/bookjar-utils/source/browse/BookJar-utils/src/util/Threads.java

On Thu, Nov 19, 2009 at 6:19 AM, David Soergel <dev at davidsoergel.com> wrote:

> Hi David,
>
> I'm not familiar with F# specifically, but you're right that using a
> functional programming style is the idea here :)
>
> Regarding the DepthFirstThreadPoolExecutor, my expectation is that it's
> only used internally.  I didn't just make it private since I figured it
> might come in handy in some other context, but in fact I've only ever used
> it from within the Parallel class.  Still, I should synchronize it properly
> just in case. Thanks for catching that!
>
> -ds
>
>
> On Nov 18, 2009, at 10:04 PM, David Holmes wrote:
>
> > David,
> >
> > Looks very F# like :)
> >
> > One thing (and I was just browsing) your DepthFirstThreadPoolExecutor
> > lifecycle management is not thread-safe. You can leak instances; there's
> no
> > sync or volatile to ensure visibility of the newly created instance, or
> of
> > updated cpu counts. There's no sync between shutting down and recreating.
> Is
> > the expectation that this will not be used directly but only from other
> > library internals which ensures a single-thread manages the executor? If
> not
> > then you need synchronization in various places.
> >
> > Cheers,
> > David Holmes
> >
> >> -----Original Message-----
> >> From: concurrency-interest-bounces at cs.oswego.edu
> >> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of David
> >> Soergel
> >> Sent: Thursday, 19 November 2009 3:40 PM
> >> To: concurrency-interest at cs.oswego.edu
> >> Subject: [concurrency-interest] Conja-- an accidental jsr166y
> >> alternative
> >>
> >>
> >> Hi all,
> >>
> >> I wrote a Java concurrency library a while back before I knew
> >> about jsr166y, and finally got around to writing up how it works.
> >> I realize I'm very late to the party here, but still I hope some
> >> of the ideas I implemented may interest you.
> >>
> >> The main advantage of my library that I see at the moment is that
> >> it hides all the hard stuff behind syntactic sugar, and so should
> >> be very easy for a novice to adopt.  I suspect it would be
> >> straightforward to provide a similarly easy-to-use wrapper around
> >> the jsr166y internals.  I haven't yet done a detailed comparison
> >> though, so it may well be that jsr166y provides functionality
> >> that Conja lacks.
> >>
> >> The project home page is at
> >> http://dev.davidsoergel.com/trac/conja/, and the most important
> >> design issues are described briefly at
> >> http://dev.davidsoergel.com/trac/conja/wiki/PrinciplesOfOperation
> >>
> >> A couple of those issues are: 1) I schedule nested tasks in
> >> depth-first order, with advantages much like work stealing; 2) I
> >> employ various strategies to conserve memory (primarily by not
> >> leaving tasks waiting around in queues); and 3) I construct
> >> Runnables lazily and concurrently from an iterator of task
> >> inputs.  One consequence is that "pipelines" consisting of nested
> >> mapping iterators (i.e., iterators that apply a function to
> >> elements from an underlying iterator) can be used to provide the
> >> inputs, in which case the mappings are computed lazily and concurrently.
> >>
> >> I've been using this for some time with excellent performance, so
> >> I think it works at least :)
> >>
> >> Looking forward to any feedback you may have,
> >>
> >> -ds
> >>
> >>
> >> _______________________________________________________
> >> David Soergel                            (650) 303-5324
> >> dev at davidsoergel.com        http://www.davidsoergel.com
> >> _______________________________________________________
> >>
> >>
> >>
> >> _______________________________________________
> >> Concurrency-interest mailing list
> >> Concurrency-interest at cs.oswego.edu
> >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
>
>
> _______________________________________________________
> David Soergel                            (650) 303-5324
> dev at davidsoergel.com        http://www.davidsoergel.com
> _______________________________________________________
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20091119/3cc52ab0/attachment-0001.html>


More information about the Concurrency-interest mailing list