|
Re: Objects as Actors
|
Posted: May 2, 2009 1:10 AM
|
|
> Actors are not automatically thread-safe.
I just showed you above that they are. Can you explain to me why they are not?
> Running your actor's message loop while the actor is in > the middle of processing another message will likely > corrupt that actor's state, in exactly the same way that > two C threads accessing the same struct without proper > locking will likely corrupt the struct.
No, it's not the same.
In the case of actors, the programmer can easily control the modification of state. He can use a debugger and check the call stack to see what's happening. In the context of actors, the middle-of-call modification is the same as calling another function in the middle of another one.
In the case of C threads, the situation is uncontrollable unless mutexes are used. Each CPU core may have a different version of the same state in its registers.
> > ** > > Automatically parallelizing code written in a language > with mutable state is a recipie for disaster.
I have used the OO actor model recently in a project of the company at work at, and it works greatly. I have 10 to 20 actors at each time active, all communicating by sending messages to each other, and the application scales wonderfully. I never see more than 1% of processing load in the task manager, and the UI is very smooth. The application logic is quite complex and requires the coordination of many external devices, but I never had a deadlock issue or anything else.
> It would > require static analysis to ensure that neither of the > computations being parallelized changes any state accessed > by the other.
No static analysis is required, as no state is changed by more than one thread.
In order to be useful, it would also require > rewriting some program structures in ways more complex > than simply replacing function calls with messages and > futures (such as splitting loops and generating arrays of > futures for intermediate results, like the rewriting > mentioned in my first post to this thread).
It's only those operations on arrays that can't be parallelized automatically by replacing the code with futures and messages. Well, nothing is perfect.
> Automatically paralellizing code is only possible in the > first place when one computation is followed by another > computation which does not use the results of the first > computation (the sum() example). I suspect > this to be rather uncommon, but there doesn't seem to be > any evidence either way.
I never said that a sequence of dependent operations becomes magically parallel. I said that whatever parallelism is there, it is automatically exposed by the OO actor model.
|
|