√iktor Ҡlang | 3 Jul 00:48 2011
Picon

ForkJoin and Akka Actors

Ladies(?) and Gentlemen,

I recently (yesterday) attempted to create an Akka Actor Dispatcher using the Scala embedded version of the ForkJoin library, just wanted to verify that I'm doing the Right Thing™

Here's a link to the code: https://github.com/jboner/akka/blob/master/akka-actor/src/main/scala/akka/dispatch/FJDispatcher.scala

The design:

Since I'm just forking and never doing any joining, I've done "setAsyncMode(true)" on the ForkJoinPool.
Each Actors mailbox is a Runnable, and to avoid extra allocations I'm weaving in FJMailbox that wraps the mailbox as a ForkJoinTask so I can reuse it.

The mailbox is only available in the pool in a binary fashion (it's added to the pool when a message is added, if messages are added and it's already in the pool it just adds the message to the mailbox,  and it's removed from the pool when the processing is completed).

If a mailbox is added to the pool, and it's done so by a ForkJoinWorkerThread, I use ForkJoinTask.fork(), and if not, I simply add it to the pool. (I always reinitialize it before doing so), here's the code for that: https://github.com/jboner/akka/blob/master/akka-actor/src/main/scala/akka/dispatch/FJDispatcher.scala#L73

At the end of processing a mailbox, it will, if it's done by a ForkJoinWorkerThread, it will call helpQuiesce() to make sure that things are getting processed. (It wasn't working until I found out I needed to call helpQuiesce)

Am I on the right track here?

Cheers,



--
Viktor Klang

Akka Tech Lead

Typesafe - Enterprise-Grade Scala from the Experts

Twitter: <at> viktorklang

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest <at> cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
dmitry.miltsov | 3 Jul 18:03 2011
Picon

Auto Reply: Concurrency-interest Digest, Vol 78, Issue 1

This is an auto-replied message.
I'm on vacation from July 1, returning to the office on July 11.

My backup persons are:
java.lang - Victor Rudometov;
java.security, javax.security - Paul Rank;
java.text, java.util - Yuri Gaevsky.

Please contact my manager Pavel Klodin regarding other issues. 

Thanks,
Dmitry Miltsov
Victor Grazi | 4 Jul 17:32 2011
Picon

JSR166Y for Java SE 5

Does anyone know if there is a version of JSR166Y for Java 5?

I would like to keep Java Concurrent Animated compatible with Java 5 but in order to illustrate Fork and Join I need JSR 166Y which I am only finding built using Java 6
Any advice?
Thanks, Victor
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest <at> cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Doug Lea | 4 Jul 17:53 2011

Re: ForkJoin and Akka Actors

On 07/02/11 18:48, √iktor Ҡlang wrote:
> I recently (yesterday) attempted to create an Akka Actor Dispatcher using the
> Scala embedded version of the ForkJoin library,

First off, you should probably target/use/test with the
current versions, either in jdk7 (snapshots but apparently
to be released soon) or the jsr166y equivalents. Hopefully
the Scala releases will adjust to do this soon rather than
carrying around outdated ones.

>
> Here's a link to the code:
> https://github.com/jboner/akka/blob/master/akka-actor/src/main/scala/akka/dispatch/FJDispatcher.scala
>
> The design:
>
> Since I'm just forking and never doing any joining, I've done
> "setAsyncMode(true)" on the ForkJoinPool.

This is probably the right approach for messaging, since it
processes tasks in per-thread-FIFO order. Beware that there
is much less builtin support for this mode than normal
recursive-task-based mode.

> Each Actors mailbox is a Runnable, and to avoid extra allocations I'm weaving in
> FJMailbox that wraps the mailbox as a ForkJoinTask so I can reuse it.
>
> If a mailbox is added to the pool, and it's done so by a ForkJoinWorkerThread, I
> use ForkJoinTask.fork(), and if not, I simply add it to the pool. (I always
> reinitialize it before doing so),

Make sure you don't reinitialize if the task was ever cancelled
or completed with an exception, since in those cases other threads
may not see completion before the reset.

> here's the code for that:
> https://github.com/jboner/akka/blob/master/akka-actor/src/main/scala/akka/dispatch/FJDispatcher.scala#L73
>

In current ForkJoinPool, the submit/execute methods already automate
the internal-fork vs external-submission decision so you can/should skip
this.

> At the end of processing a mailbox, it will, if it's done by a
> ForkJoinWorkerThread, it will call helpQuiesce() to make sure that things are
> getting processed.

Yes, helpQuiesce is possible here. There are also the protected
methods pollNextLocalTask and related support for locally
processing tasks. If tasks are never joined, then the pool
mechanics don't otherwise help ensure timely completion.

-Doug

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest <at> cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Doug Lea | 4 Jul 18:00 2011

Re: JSR166Y for Java SE 5

On 07/04/11 11:32, Victor Grazi wrote:
> Does anyone know if there is a version of JSR166Y for Java 5?

The main Java5 incompatibility is reliance on some new intrinsics
that were added in Java6. It is possible to work around these
(mainly by using putVolatileX instead of putOrderedX), with
a fair amount of performance loss. I know people have done this
(including in some of the embedded Scala versions mentioned in
my last mail), but don't know of general availability. (Plus I
don't want to go on record as doing anything that would
encourage anyone not upgrade from Java5!)

-Doug
Attila Szegedi | 4 Jul 18:33 2011
Picon

Re: ForkJoin and Akka Actors

Out of curiosity, since you're just forking and never joining, what is the benefit of using the forkjoin classes instead of a plain thread pool executor with a queue? Do you get some additional efficiency benefits from work stealing behavior?

Attila.

On Jul 2, 2011, at 3:48 PM, √iktor Ҡlang wrote:

Ladies(?) and Gentlemen,

I recently (yesterday) attempted to create an Akka Actor Dispatcher using the Scala embedded version of the ForkJoin library, just wanted to verify that I'm doing the Right Thing™

Here's a link to the code: https://github.com/jboner/akka/blob/master/akka-actor/src/main/scala/akka/dispatch/FJDispatcher.scala

The design:

Since I'm just forking and never doing any joining, I've done "setAsyncMode(true)" on the ForkJoinPool.
Each Actors mailbox is a Runnable, and to avoid extra allocations I'm weaving in FJMailbox that wraps the mailbox as a ForkJoinTask so I can reuse it.

The mailbox is only available in the pool in a binary fashion (it's added to the pool when a message is added, if messages are added and it's already in the pool it just adds the message to the mailbox,  and it's removed from the pool when the processing is completed).

If a mailbox is added to the pool, and it's done so by a ForkJoinWorkerThread, I use ForkJoinTask.fork(), and if not, I simply add it to the pool. (I always reinitialize it before doing so), here's the code for that: https://github.com/jboner/akka/blob/master/akka-actor/src/main/scala/akka/dispatch/FJDispatcher.scala#L73

At the end of processing a mailbox, it will, if it's done by a ForkJoinWorkerThread, it will call helpQuiesce() to make sure that things are getting processed. (It wasn't working until I found out I needed to call helpQuiesce)

Am I on the right track here?

Cheers,



--
Viktor Klang

Akka Tech Lead
Typesafe - Enterprise-Grade Scala from the Experts

Twitter: <at> viktorklang

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest <at> cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest <at> cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
√iktor Ҡlang | 4 Jul 21:10 2011
Picon

Re: ForkJoin and Akka Actors


On Jul 4, 2011 6:00 PM, "Doug Lea" <dl <at> cs.oswego.edu> wrote:
>
> On 07/02/11 18:48, √iktor Ҡlang wrote:
>>
>> I recently (yesterday) attempted to create an Akka Actor Dispatcher using the
>> Scala embedded version of the ForkJoin library,
>
>
> First off, you should probably target/use/test with the
> current versions, either in jdk7 (snapshots but apparently
> to be released soon) or the jsr166y equivalents. Hopefully
> the Scala releases will adjust to do this soon rather than
> carrying around outdated ones.

Indeed, unfortunately I have a 0 external dependency restriction for this, so hopefully it'll be updated in Scala library for 2.10

>
>
>>
>> Here's a link to the code:
>> https://github.com/jboner/akka/blob/master/akka-actor/src/main/scala/akka/dispatch/FJDispatcher.scala
>>
>> The design:
>>
>> Since I'm just forking and never doing any joining, I've done
>> "setAsyncMode(true)" on the ForkJoinPool.
>
>
> This is probably the right approach for messaging, since it
> processes tasks in per-thread-FIFO order. Beware that there
> is much less builtin support for this mode than normal
> recursive-task-based mode.

Yeah, I can imagine. I'm not fully clear on priorities of other workers, they'll only steal work when quiscing?

>
>> Each Actors mailbox is a Runnable, and to avoid extra allocations I'm weaving in
>> FJMailbox that wraps the mailbox as a ForkJoinTask so I can reuse it.
>>
>> If a mailbox is added to the pool, and it's done so by a ForkJoinWorkerThread, I
>> use ForkJoinTask.fork(), and if not, I simply add it to the pool. (I always
>> reinitialize it before doing so),
>
>
> Make sure you don't reinitialize if the task was ever cancelled
> or completed with an exception, since in those cases other threads
> may not see completion before the reset.

Ouch, that sounds nasty, what's the recommended work-around?

>
>
>
>> here's the code for that:
>> https://github.com/jboner/akka/blob/master/akka-actor/src/main/scala/akka/dispatch/FJDispatcher.scala#L73
>>
>
> In current ForkJoinPool, the submit/execute methods already automate
> the internal-fork vs external-submission decision so you can/should skip
> this.

Yeah, I was unsure on the behavior of the Scala Library embedded version.

Also, there can logically be several distinct dispatchers, so I need to make sure that it's not only a FJWorkerThread, but that the current thread belongs to the pool of the mailbox FJTask, is that done by auto?


>
>
>> At the end of processing a mailbox, it will, if it's done by a
>> ForkJoinWorkerThread, it will call helpQuiesce() to make sure that things are
>> getting processed.
>
>
> Yes, helpQuiesce is possible here. There are also the protected
> methods pollNextLocalTask and related support for locally
> processing tasks.

Alright, but what about stealing? Because it's important that Stealing is done so that other workers can help out

If tasks are never joined, then the pool
> mechanics don't otherwise help ensure timely completion.

Thanks for helping me sort this out,


Cheers,




>
> -Doug
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest <at> cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest <at> cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Victor Grazi | 4 Jul 23:50 2011
Picon

Java Concurrent Animated update

I wanted to announce that Java Concurrent Animated now contains some new animations.

Fork and Join and ConcurrentHashMap have been added.

Also ReentrantLock has LockInterruptibly and interrupt buttons.

Besides that are a few bug fixes an better organization.

I would appreciate any feedback, especially on the new features

Thanks, Victor Grazi
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest <at> cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Doug Lea | 5 Jul 13:58 2011

Re: ForkJoin and Akka Actors

On 07/04/11 12:33, Attila Szegedi wrote:
> Out of curiosity, since you're just forking and never joining, what is the
> benefit of using the forkjoin classes instead of a plain thread pool executor
> with a queue? Do you get some additional efficiency benefits from work stealing
> behavior?
>

Even though the primary design point of ForkJoin was
supporting efficient data-parallel operations,
I've heard increasing reports from people that it
seems to work well for some middleware applications.
The combination of cheap "fork" operations,
bundling of control and actions within ForkJoinTask,
decentralized work-stealing, automation of (some)
starvation avoidance, and so on, together can lead to much
better throughput than ThreadPoolExecutor. But sometimes
does not, mainly because FJ tends to require more
per-core/thread CPU activity.

Since middleware applications were not our main
focus (we even tried to rule some out by for example
not allowing IOExceptions), there isn't yet very
much support for them. (And at this point, not much
good guidance about when they are worth considering.)
But we plan to add some, probably at first with
some misc utilities, including some ManagedBlocker
adaptors for performing more kinds of blocking IO/sync,
plus a form of ForkJoinTask that better tolerates
one subtask being "stuck" in IO/sync that other workers
in computation trees are unable to help with.
And probably more. Stay tuned...

-Doug
Doug Lea | 5 Jul 14:12 2011

Re: ForkJoin and Akka Actors

On 07/04/11 15:10, √iktor Ҡlang wrote:
>  > This is probably the right approach for messaging, since it
>  > processes tasks in per-thread-FIFO order. Beware that there
>  > is much less builtin support for this mode than normal
>  > recursive-task-based mode.
>
> Yeah, I can imagine. I'm not fully clear on priorities of other workers, they'll
> only steal work when quiscing?

When a task completes, the thread first tries to exec the next task
in its local queue, then tries to steal, then tries to start on
a new pool submission, then eventually (after various retry
and consensus mechanics) gives up and blocks waiting
for work.

>  > Make sure you don't reinitialize if the task was ever cancelled
>  > or completed with an exception, since in those cases other threads
>  > may not see completion before the reset.
>
> Ouch, that sounds nasty, what's the recommended work-around?

You probably want to do something like:
   if (task.isCompletedNormally())
      task.reinitialize();
   else
       task = new ...Task(...); // clone

>
> Also, there can logically be several distinct dispatchers, so I need to make
> sure that it's not only a FJWorkerThread, but that the current thread belongs to
> the pool of the mailbox FJTask, is that done by auto?

Yes.

>  > Yes, helpQuiesce is possible here. There are also the protected
>  > methods pollNextLocalTask and related support for locally
>  > processing tasks.
>
> Alright, but what about stealing?

Yes, see ForkJoinTask.pollTask(). We don't directly support polling
new submissions from ForkJoinTask, but see ForkJoinPool.pollSubmission.
We don't especially recommend using most of these for casual use though.
They are mainly meant to enable creating new abstract ForkJoinTask types
(like the ones already supplied in RecursiveAction and RecursiveTask).

-Doug

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest <at> cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Gmane