View mode: basic / threaded / horizontal-split · Log in · Help
April 19, 2008
Concurrency in D and Active Objects
Active Objects were mentioned in a thread on the NG, so I've looked
around and found the following file which explains the idea in a very
clear way. it also outline a possible implementation for C#.

http://blog.gurock.com/wp-content/uploads/2008/01/activeobjects.pdf

Since D is way better than Java/C#/C++ (all mentioned in the above
article) it seems to me that such a useful abstraction could be
implemented in D and probably would be simpler to do that than the other
languages mentioned above.

What are the benefits of D's approach of implementing a functional
subset with pure functions compared to the above abstraction of Active
Objects?
Also, to make D's functional subset run Concurrently doesn't D need a
special runtime that parallelizes the code (which D currently doesn't have)?

--Yigal
April 19, 2008
Re: Concurrency in D and Active Objects
Yigal Chripun wrote:
> Active Objects were mentioned in a thread on the NG, so I've looked
> around and found the following file which explains the idea in a very
> clear way. it also outline a possible implementation for C#.
> 
> http://blog.gurock.com/wp-content/uploads/2008/01/activeobjects.pdf
> 
> Since D is way better than Java/C#/C++ (all mentioned in the above
> article) it seems to me that such a useful abstraction could be
> implemented in D and probably would be simpler to do that than the other
> languages mentioned above.
> What are the benefits of D's approach of implementing a functional
> subset with pure functions compared to the above abstraction of Active
> Objects?

For low-level tasks (i.e. mapping a function to every element of an 
array), it's easier to write and a better solution using D's model (pure 
functions).

For high-level tasks (i.e. processing a SQL query in large database 
engine), active objects are _MUCH_ easier to work with, since they allow 
state (automatic state within functions doesn't cut it here, fellows). I 
think this is where the future of parallelization lies, not in forcing 
the user to worry about immutability and pure functions (which is not 
easy for the average programmer, I _hated_ learning FP in school).

*puts on flame-retardant vest* Maybe my mind is just too focused on 
database and web programming, but from working with an event-based 
parallelization technique (SEDA, but AO is quite similar in its 
approach, albiet more OO and by a different name), is that it's a lot 
easier to grasp for the programmer. All data outside the event needs to 
be synchronized on, of course, but a good event model uses very little 
global data.

OTOH, D's model is compiler-checkable (i.e. the compiler can guarantee 
you no sync issues), while an event/active object model is not (since 
you can access global state).

> Also, to make D's functional subset run Concurrently doesn't D need a
> special runtime that parallelizes the code (which D currently doesn't have)?

Yes, but that can be done. Active objects would need one, too.

> --Yigal
April 21, 2008
Re: Concurrency in D and Active Objects
> OTOH, D's model is compiler-checkable (i.e. the compiler can guarantee you 
> no sync issues), while an event/active object model is not (since you can 
> access global state).

It is possible to implement active objects such that global state is not 
accessible via an active object unless the global variable is synchronized 
or thread local (if thread local support were added).  What I am saying is 
that thread safety could be enforced at compile time if the right language 
features were in place.

>> Also, to make D's functional subset run Concurrently doesn't D need a
>> special runtime that parallelizes the code (which D currently doesn't 
>> have)?
>
> Yes, but that can be done. Active objects would need one, too.
>

All that would be needed for active objects is a thread pool, which is cake. 
Each active object could just be a task added to the pool.

-Craig
April 21, 2008
Re: Concurrency in D and Active Objects
Craig Black wrote:
>> OTOH, D's model is compiler-checkable (i.e. the compiler can guarantee you 
>> no sync issues), while an event/active object model is not (since you can 
>> access global state).
> 
> It is possible to implement active objects such that global state is not 
> accessible via an active object unless the global variable is synchronized 
> or thread local (if thread local support were added).  What I am saying is 
> that thread safety could be enforced at compile time if the right language 
> features were in place.

Now that would just be awesome.
April 24, 2008
Re: Concurrency in D and Active Objects
Craig Black wrote:
>>> Also, to make D's functional subset run Concurrently doesn't D need a
>>> special runtime that parallelizes the code (which D currently doesn't 
>>> have)?
>> Yes, but that can be done. Active objects would need one, too.
>>
> 
> All that would be needed for active objects is a thread pool, which is cake. 
> Each active object could just be a task added to the pool.

You could use dependency injection to give your active object a 
threadpool. Or you could use threadPool.createNew!(MyActiveClass) or 
some such.

> -Craig
> 
>
Top | Discussion index | About this forum | D home