Pure dynamic casts?

[Robert Jacques]

On Fri, 25 Sep 2009 00:07:08 -0400, Jeremie Pelletier <jeremiep at gmail.com>  
wrote:

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

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