www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Concurrency in D and Active Objects

reply Yigal Chripun <yigal100 gmail.com> writes:
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


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


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
Apr 19 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
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

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

 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
Apr 19 2008
parent reply "Craig Black" <cblack ara.com> writes:
 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
Apr 21 2008
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
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.
Apr 21 2008
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
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
 
 
Apr 24 2008