The Artima Developer Community
Sponsored Link

Artima Developer Spotlight Forum
Objects as Actors

44 replies on 3 pages. Most recent reply: Jul 26, 2009 6:55 AM by Glen Ritchie

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 44 replies on 3 pages [ « | 1 2 3 ]
Timothy Brownawell

Posts: 25
Nickname: tbrownaw
Registered: Mar, 2009

Re: Objects as Actors Posted: Apr 27, 2009 4:39 PM
Reply to this message Reply
Advertisement
> > What that one thread executes will be
> >

> > do_stuff() line 2
> > do_stuff() line 3(a)
> > <run message loop while waiting>
> > ...
> > set()
> > ...
> > do_stuff() line 3(b)
> > do_stuff() line 4
> >

> >
> > The set() call happens between lines 2 and 4
> > of do_stuff(), without necessarily being
> > called by (something called by...)
> > do_stuff(). That it what it means to be
> > non-atomic; the state that do_stuff() is
> > acting on can be changed by code not called by
> > do_stuff() while do_stuff() is
> > running. That is why entering a new message loop when
> > waiting for a result means that you're back to needing
> > explicit locking.
>
> It's the same as if do_stuff() invoked do_bar() and
> do_bar() invoked set().

Except that do_stuff() has no reason to expect set() to be called, so it will very probably do the wrong thing.

> You don't need explicit locking because you can copy the
> required state to a local variable before the do_stuff()
> happens.

Copy which state to a local variable where? And how does this handle updating the shared state with its new value? Do you have an example to show this?

> If you don't want to do that, then all you need is a state
> machine to coordinate access to 'data'. But you don't need
> mutexes and semaphores etc.

Pseudocode please? Like I've been providing to try to demonstrate my claims?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Objects as Actors Posted: Apr 27, 2009 5:28 PM
Reply to this message Reply
> You bring up a good point. Correctness is a valid concern
> but I think that applies to any compiler that optimizes
> code.

Calling 'correctness' a valid concern seems like a big understatement to me. I would call it a minimum necessary requirement.

> Modern compilers implement techniques like loop
> fission, privatization etc. You can get code for javar and
> some docs here: http://www.extreme.indiana.edu/hpjava/
> They talk a little bit about correctness and the
> conditions under which generated code can be verified. I
> didn’t see a proof checker etc., but that’s beyond me
> anyways. There are other papers and projects too on this
> subject, which is why I say automatic parallelism is
> possible. Maybe not in all cases.

I'm not saying that automatic parallelization from serial code is not possible, I just don't think it's going to amount to much in the long run.

Gary Duzan

Posts: 5
Nickname: gduzan
Registered: Apr, 2009

Re: Objects as Actors Posted: Apr 27, 2009 7:09 PM
Reply to this message Reply
> I'm not saying that automatic parallelization from serial
> code is not possible, I just don't think it's going to
> amount to much in the long run.

And the middle ground in the discussion is met when you have a language with semantics which make automatic parallelization more practical. Unfortunately, this generally means rewriting code, but if parallel processing is a goal, then it may be worth it.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Objects as Actors Posted: Apr 28, 2009 2:18 AM
Reply to this message Reply
> Except that do_stuff() has no reason to expect set() to be
> called, so it will very probably do the wrong thing.

set() could have been called from do_stuff() even if there was no parallelism. It's a matter of design.

> Copy which state to a local variable where? And how does
> this handle updating the shared state with its new value?
> Do you have an example to show this?

It's very simple:


int last_known_data = m_data;
Thing result = do_stuff();
int tmp = last_known_data * result;


>
> > If you don't want to do that, then all you need is a
> state
> > machine to coordinate access to 'data'. But you don't
> need
> > mutexes and semaphores etc.
>
> Pseudocode please? Like I've been providing to try to
> demonstrate my claims?


void set(int value) {
switch (state) {
case DontTouchData:
break;

TouchData:
data = value;
}
}

void bar() {
state = DontTouchData;
Thing result = do_stuff();
int tmp = data * result;
state = TouchData;
}

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Objects as Actors Posted: Apr 28, 2009 2:19 AM
Reply to this message Reply
> > I'm not saying that automatic parallelization from
> serial
> > code is not possible, I just don't think it's going to
> > amount to much in the long run.
>
> And the middle ground in the discussion is met when you
> have a language with semantics which make automatic
> parallelization more practical. Unfortunately, this
> generally means rewriting code, but if parallel processing
> is a goal, then it may be worth it.

Especially if the code writing style can be made not to differ with the current style, as in the case of OO actors.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Objects as Actors Posted: Apr 28, 2009 7:27 AM
Reply to this message Reply
> > I'm not saying that automatic parallelization from
> serial
> > code is not possible, I just don't think it's going to
> > amount to much in the long run.
>
> And the middle ground in the discussion is met when you
> have a language with semantics which make automatic
> parallelization more practical. Unfortunately, this
> generally means rewriting code, but if parallel processing
> is a goal, then it may be worth it.

Well stated. However, I think that a lot of libraries are not going to need to be parallelized internally. My experience is that parallelization makes more sense at a macro level anyways. Forking small loops and parallelizing processes with lots of locking tends to have minimal to negative performance impact. So a lot of java code (of C# or C++) is fine the way it is. A new language that can make use of existing libraries would be optimal. Some libraries will need to be rewritten or replaced, of course but the big change will be in the higher-level application logic.

Timothy Brownawell

Posts: 25
Nickname: tbrownaw
Registered: Mar, 2009

Re: Objects as Actors Posted: Apr 28, 2009 4:21 PM
Reply to this message Reply
> > Copy which state to a local variable where? And how does
> > this handle updating the shared state with its new value?
> > Do you have an example to show this?
>
> It's very simple:
>
>

> int last_known_data = m_data;
> Thing result = do_stuff();
> int tmp = last_known_data * result;
>


So how does this prevent set() from stepping on do_stuff()? Is it meant to entirely replace line 4 (data = ...) in do_stuff(), so that instead of updating shared state it returns the new state to the caller?

> > > If you don't want to do that, then all you need is a state
> > > machine to coordinate access to 'data'. But you don't need
> > > mutexes and semaphores etc.
> >
> > Pseudocode please? Like I've been providing to try to
> > demonstrate my claims?
>
>

> void set(int value) {
> switch (state) {
> case DontTouchData:
> break;
>
> TouchData:
> data = value;
> }
> }
>
> void bar() {
> state = DontTouchData;
> Thing result = do_stuff();
> int tmp = data * result;
> state = TouchData;
> }
>


So just completely discard the set() call? That will (depending on what exactly the calculations in do_stuff() are) give a different final state than the set() call happening either entirely before or after the do_stuff() call, probably not what's wanted.

What if instead of set() being called in the middle of do_stuff() it's do_stuff() being called twice at the same time?

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Objects as Actors Posted: Apr 29, 2009 4:14 AM
Reply to this message Reply
> So how does this prevent set() from stepping
> on do_stuff()? Is it meant to entirely
> replace line 4 (data = ...) in
> do_stuff(), so that instead of updating
> shared state it returns the new state to the caller?

set() may be invoke while do_stuff() runs, but the data field required by the calculation of data with the result of do_stuff() will not change.

> So just completely discard the set() call?
> That will (depending on what exactly the calculations in
> do_stuff() are) give a different final state
> than the set() call happening either entirely
> before or after the do_stuff() call, probably
> not what's wanted.

It depends on what is required, but obviously both can easily be done.

>
> What if instead of set() being called in the
> middle of do_stuff() it's
> do_stuff() being called twice at the same
> time?

It's no different than a recursive call.

Timothy Brownawell

Posts: 25
Nickname: tbrownaw
Registered: Mar, 2009

Re: Objects as Actors Posted: Apr 29, 2009 5:52 PM
Reply to this message Reply
> > So how does this prevent set() from
> stepping
> > on do_stuff()? Is it meant to entirely
> > replace line 4 (data = ...) in
> > do_stuff(), so that instead of updating
> > shared state it returns the new state to the caller?
>
> set() may be invoke while do_stuff() runs, but the data
> field required by the calculation of data with the result
> of do_stuff() will not change.
>
> > So just completely discard the set() call?
> > That will (depending on what exactly the calculations
> in
> > do_stuff() are) give a different final
> state
> > than the set() call happening either
> entirely
> > before or after the do_stuff() call,
> probably
> > not what's wanted.
>
> It depends on what is required, but obviously both can
> easily be done.
>
> >
> > What if instead of set() being called in
> the
> > middle of do_stuff() it's
> > do_stuff() being called twice at the same
> > time?
>
> It's no different than a recursive call.

I don't see how those address what I've been trying to get at, so I guess we must just be talking past eachother here. Ah well...

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Objects as Actors Posted: Apr 30, 2009 3:36 AM
Reply to this message Reply
> I don't see how those address what I've been trying to get
> at, so I guess we must just be talking past eachother
> here. Ah well...

Ok, tell me. I am interested, perhaps I haven't understood well.

Timothy Brownawell

Posts: 25
Nickname: tbrownaw
Registered: Mar, 2009

Re: Objects as Actors Posted: May 1, 2009 6:05 PM
Reply to this message Reply
Actors are not automatically thread-safe.

It is possible to implement a Mutex actor in erlang: http://james-iry.blogspot.com/2009/04/erlang-style-actors-are-all-about_16.html

Actors are sharable mutable state: http://james-iry.blogspot.com/2009/04/erlang-style-actors-are-all-about.html

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.

**

Automatically parallelizing code written in a language with mutable state is a recipie for disaster. It would require static analysis to ensure that neither of the computations being parallelized changes any state accessed by the other. 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).

**

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.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Objects as Actors Posted: May 2, 2009 1:10 AM
Reply to this message Reply
> 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.

Timothy Brownawell

Posts: 25
Nickname: tbrownaw
Registered: Mar, 2009

Re: Objects as Actors Posted: May 2, 2009 7:30 AM
Reply to this message Reply
> > Actors are not automatically thread-safe.
>
> I just showed you above that they are. Can you explain to
> me why they are not?

This is demonstrated with actual examples in those links I provided, if you care to read them.

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

Actors are stateful (see links). A given actor can be accessed by more than one concurrent computation. Therefore actors are state which can be changed by more than one concurrent computation (aka "thread" when talking about being thread-safe).

I think you're being confused by the word "thread" here. Threads are an implementation detail, they don't actually matter. What does matter is when multiple things can happen at the same time or in a nondeterministic order. That only one physical thread touches the state, does not matter. What matters is that any number of concurrent computations can cause that state to change (by sending messages to the actor responsible for it) or observe changes in the state (by receiving messages from that actor).

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Objects as Actors Posted: May 3, 2009 2:28 AM
Reply to this message Reply
I do not see the state change as a problem, as you say, since the programmer can control the state change.

To put it differently: with actors, you dont need low level locks, and therefore it is much easier to make multi-threaded algorithms. With low level locks, you need to be extremely careful not to introduce deadlocks which make debugging impossible.

Glen Ritchie

Posts: 12
Nickname: gmanndsu
Registered: Dec, 2004

Re: Objects as Actors Posted: Jul 26, 2009 6:55 AM
Reply to this message Reply
Whew!!! Quite some exchange.

= I have one question. Where did "using messages" to define OOP come from? Was it in Smalltalk originally?

Or was "Bindu Rao's book," C++ and the Oop Paradigm.

= Or the term "Actor" as an abstraction with OOP. Parallelism wasn't that formerly understood, at the time, was it.

Thanks in advance. (I have no code samples!)

Flat View: This topic has 44 replies on 3 pages [ « | 1  2  3 ]
Topic: Ed Ort Explains invokedynamic Previous Topic   Next Topic Topic: Adobe's Rob Christensen on AIR

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use