On Fri, 25 Sep 2009 00:07:08 -0400, Jeremie Pelletier <jerem...@gmail.com>
wrote:
Robert Jacques wrote:
On Thu, 24 Sep 2009 20:59:23 -0400, Jeremie Pelletier
<jerem...@gmail.com> wrote:
Robert Jacques wrote:
On Thu, 24 Sep 2009 20:46:13 -0400, Jeremie Pelletier
<jerem...@gmail.com> wrote:
[snip]
Its the same for concurrency, I can think of vector processing,
functional calls, STM, message passing and shared memory off the top
of my head. All being valid models with each their pros and cons,
together forming a complete all-around solution.
Jeremie
Don't forget task-based or lock-free.
Oh yeah, thanks! Those were covered by Bartosz in his blog right? I
think he used the term Actor for task based programming, I really
enjoyed reading these articles.
There are many things called Actors, but they generally boil down to a
process/thread/object + message passing. It's a good model,
particularly for the cloud. Task programming is generally
intra-process and works on the level of a single work-task (aka
function). Cilk, futures or Intel's Threading Building Blocks are the
canonical examples. The nice thing (I think) about a good work-stealing
runtime is that it can provide the back-end for CPU-vector processing,
tasks/futures, intra-process actors and functional calls.
I think the best way to deal with actors is by making them objects.
Binding them to heavyweight kernel structures such as threads and
processes will greatly limit the number of concurrent actors you can
execute at once.
Tasks would be most likely implemented by async methods, since you don't
care about knowing when they're done. On the other hand, futures are
there when you need an async call and monitor its completion.
A good implementation could therefore easily support tens of thousands
of concurrent actors.
I must admit its the first time I hear about work-stealing, I will need
to do some research on that :)
:) I prefer Actor's being objects with async methods too.
Anyways here's the work-stealing concept in brief:
Each thread/actor keeps a set of tasks to be done. This avoids having a
single point of contention for task creation/assignment. When a worker
thread runs out of tasks it then steals tasks from other actors/threads.
Both Cilk and Intel's TTB are good places to start reading. For low
latency, futures require a set with efficient random removal. I.e. the
promise becomes due, so the current thread assigns the associated future
to itself. Actors, on the other hand, should be limited to FIFO, to
maintain consistency. Though mutable methods would require exclusive
access, in theory const and immutable methods should be able to be run in
parallel with each other.
