Pure dynamic casts?

[Jeremie Pelletier]

Robert Jacques wrote:
> On Thu, 24 Sep 2009 20:59:23 -0400, Jeremie Pelletier 
> <jeremiep at gmail.com> wrote:
> 
>> Robert Jacques wrote:
>>> On Thu, 24 Sep 2009 20:46:13 -0400, Jeremie Pelletier 
>>> <jeremiep at 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 :)