This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Determining if actors really multi-thread

1 reply
Derek Chen-Becker
Joined: 2008-12-16,
User offline. Last seen 42 years 45 weeks ago.

OK, so I think I have a better understanding of how Actors work, but I'm
still not sure if Actors are appropriate for what I'm doing. Essentially
I have 3000 tasks that run once (no event loop) that use blocking I/O
over the network, and so have quite a bit of variation in their latency.
Right now, I can use the ExecutorService in java.util.concurrent
essentially as a task queue to set up the 3000 tasks, let them run and
then call shutdown on the ExecutorService at the end to wait for all of
the tasks to complete. As each task completes, it adds a message object
to a blocking queue, which a single thread pulls from to update a
database. I can easily see how Actors work in the latter half of this,
but I'm still not sure what the most appropriate method would be for the
first half. Here are the options as I see them:

1. Create one Actor for the tasks and submit 3000 messages. This has a
big drawback that the Actor only runs on one thread at a time, so with
the blocking I/O it could take a very long time to complete.

2. Create 3000 Actors, one for each task. Simple, but how much overhead
is there for an Actor instance? How far does this scale?

3. Create N Actors and divvy up 3000/N tasks to each one. Not exactly a
fan of this one since it requires manual partitioning of the tasks.

4. Just leave my code the way it is. It works fine now, so I don't
necessarily need to change it.

I really appreciate everyone's feedback on this so far. I definitely
understand Actors better now.

Thanks,

Derek

David Pollak
Joined: 2008-12-16,
User offline. Last seen 42 years 45 weeks ago.
Determining if actors really multi-thread

Derek,

There's a library that bridges between Mina (an nio library) and actors.  It might be just what you need.

Thanks.

David

On Dec 16, 2008 7:06 AM, "Derek Chen-Becker" <java [at] chen-becker [dot] org> wrote:

OK, so I think I have a better understanding of how Actors work, but I'm
still not sure if Actors are appropriate for what I'm doing. Essentially
I have 3000 tasks that run once (no event loop) that use blocking I/O
over the network, and so have quite a bit of variation in their latency.
Right now, I can use the ExecutorService in java.util.concurrent
essentially as a task queue to set up the 3000 tasks, let them run and
then call shutdown on the ExecutorService at the end to wait for all of
the tasks to complete. As each task completes, it adds a message object
to a blocking queue, which a single thread pulls from to update a
database. I can easily see how Actors work in the latter half of this,
but I'm still not sure what the most appropriate method would be for the
first half. Here are the options as I see them:

1. Create one Actor for the tasks and submit 3000 messages. This has a
big drawback that the Actor only runs on one thread at a time, so with
the blocking I/O it could take a very long time to complete.

2. Create 3000 Actors, one for each task. Simple, but how much overhead
is there for an Actor instance? How far does this scale?

3. Create N Actors and divvy up 3000/N tasks to each one. Not exactly a
fan of this one since it requires manual partitioning of the tasks.

4. Just leave my code the way it is. It works fine now, so I don't
necessarily need to change it.

I really appreciate everyone's feedback on this so far. I definitely
understand Actors better now.

Thanks,

Derek

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland