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 :)
