Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Actors: A Model of Concurrent Computation [pdf] (1985)

apps.dtic.mil

Post reply on HN
Print view View original

41–50 of 80 posts

Re: Actors: A Model of Concurrent Computation [pdf] (1985)

#41

Post by Weryj »

mjlawson wrote: post #27
BatteryMountain wrote: post #12

Earlier quoted context omitted.

Orleans is pretty cool! The project has matured nicely over the years (been something like 10 years?) and they have some research papers attached to it if you like reading up on the details. The nuget stats indicate a healthy amount of downloads too, more than one might expect. One of the single most important things I've done in my career was going down the Actor Model -framework rabbit hole about 8 or 9 years ago,…

Do any of the books you read on the topic stand out as something you'd recommend?

You can always join the Orleans Discord

Re: Actors: A Model of Concurrent Computation [pdf] (1985)

#42

Post by brabel »

lmm wrote: post #14
galaxyLogic wrote: post #9

Earlier quoted context omitted.

> both the actor model (and its relative, CSP) in non-distributed systems solely in order to achieve concurrency has been a massive boondoggle and a huge dead end. Why is that so?

Well, lots of people have tried it and spent a lot of money on it and don't seem to have derived any benefit from doing so.

Actors can be made to do structured concurrency as long as you allow actors to wait for responses from other actors, and implement hierarchy so if an actor dies , its children do as well. And that’s how I use them! So I have to say the OP is just ignorant of how actors are used in practice.

Re: Actors: A Model of Concurrent Computation [pdf] (1985)

#43

Post by neonsunset »

logicchains wrote: post #38
kibwen wrote: post #5

Please change the title to the original, "Actors: A Model Of Concurrent Computation In Distributed Systems". I'm not normally a stickler for HN's rule about title preservation, but in this case the "in distributed systems" part is crucial, because IMO the urge to use both the actor model (and its relative, CSP) in non-distributed systems solely in order to achieve concurrency has been a massive boondoggle and a huge…

CSP in Golang makes concurrency in it look pleasant compared to the async monstrosities I've seen in C#.

[dead]

Re: Actors: A Model of Concurrent Computation [pdf] (1985)

#44

Post by zozbot234 »

whizzter wrote: post #40
koakuma-chan wrote: post #22

Earlier quoted context omitted.

So you're just using actors to limit concurrency? Why not use a mutex?

In this simple case they're more or less equivalent if the only task is limiting concurrency, but in general usage of mutexes multiplies and soon enough someone else has created a deadlock situation. Extending it however reveals some benefits, locking is often for stopping whilst waiting for something enqueued can be parallell with waiting for something else that is enqueued. I think it very much comes down to histor…

Atomic operations, memory barriers, condition variables, thread/"virtual processor" scheduling are philosophically cleaner since they're what the specified hardware/OS concurrency model actually provides, and can implement all of locks, mutexes, structured concurrency, arbitrary queues, actors etc. etc.

Re: Actors: A Model of Concurrent Computation [pdf] (1985)

#45

Post by ahoka »

raphinou wrote: post #21
kibwen wrote: post #5

Please change the title to the original, "Actors: A Model Of Concurrent Computation In Distributed Systems". I'm not normally a stickler for HN's rule about title preservation, but in this case the "in distributed systems" part is crucial, because IMO the urge to use both the actor model (and its relative, CSP) in non-distributed systems solely in order to achieve concurrency has been a massive boondoggle and a huge…

I'm working on an rest API server backed by a git repo. Having an actor responsible for all git operations saved me from a lot of trouble as having all git operations serialised freed me from having to prevent concurrent git operations. Using actors also simplified greatly other parts of the app.

Isn’t that just serializing through a queue, aka. the producer consumer pattern? Which I think the correct solution for most common concurrency problems.

For something to be an actor, it should be able to:

- Send and receive messages

- Create other actors

- Change how the next message is handled (becomes in Erlang)

I think the last one is what makes it different it from simple message passing, and what makes it genius: state machines consuming queues.

Re: Actors: A Model of Concurrent Computation [pdf] (1985)

#46

Post by kibwen »

brabel wrote: post #42
lmm wrote: post #14

Earlier quoted context omitted.

Well, lots of people have tried it and spent a lot of money on it and don't seem to have derived any benefit from doing so.

Actors can be made to do structured concurrency as long as you allow actors to wait for responses from other actors, and implement hierarchy so if an actor dies , its children do as well. And that’s how I use them! So I have to say the OP is just ignorant of how actors are used in practice.

To adapt the analogy from the link in the root comment, this is akin to saying "`goto` can be made to do structured programming as long as you strictly ensure that the control flow graph is reducible". Which is to say, it is a true statement that manages to miss the point: the power of both structured programming and structured concurrency comes from defining new primitives that fundamentally do the right thing and don't even give you the option to do the wrong thing, thus producing a more reliable system. There's no "as long as you...", it just works.

Re: Actors: A Model of Concurrent Computation [pdf] (1985)

#47

Post by kibwen »

logicchains wrote: post #38
kibwen wrote: post #5

Please change the title to the original, "Actors: A Model Of Concurrent Computation In Distributed Systems". I'm not normally a stickler for HN's rule about title preservation, but in this case the "in distributed systems" part is crucial, because IMO the urge to use both the actor model (and its relative, CSP) in non-distributed systems solely in order to achieve concurrency has been a massive boondoggle and a huge…

CSP in Golang makes concurrency in it look pleasant compared to the async monstrosities I've seen in C#.

I heartily recommend reading the link the parent comment on structured concurrency. The alternatives here are not merely goroutines vs. async.

Re: Actors: A Model of Concurrent Computation [pdf] (1985)

#48

Post by ahoka »

rurban wrote: post #30
koakuma-chan wrote: post #22

Earlier quoted context omitted.

So you're just using actors to limit concurrency? Why not use a mutex?

Because actors were invented to overcome deadlocks caused by mutexes. See page 137. With mutexes you can forget concurrency safety.

I’m pretty sure it’s possible to deadlock an actor system.

Re: Actors: A Model of Concurrent Computation [pdf] (1985)

#49

Post by kibwen »

eaurouge wrote: post #35
kibwen wrote: post #5

Please change the title to the original, "Actors: A Model Of Concurrent Computation In Distributed Systems". I'm not normally a stickler for HN's rule about title preservation, but in this case the "in distributed systems" part is crucial, because IMO the urge to use both the actor model (and its relative, CSP) in non-distributed systems solely in order to achieve concurrency has been a massive boondoggle and a huge…

Nurseries sound similar to run-till-completion schedulers [0]. > IMO the urge to use both the actor model (and its relative, CSP) in non-distributed systems solely in order to achieve concurrency has been a massive boondoggle Can't you model any concurrent non-distributed system as a concurrent distributed system? 0. https://en.wikipedia.org/wiki/Run-to-completion_scheduling

> Can't you model any concurrent non-distributed system as a concurrent distributed system?

Yes, in the same way that you can give up `for` loops and `while` loops and `if` statements and `switch` statements and instead write them all with `goto`, but you don't do this, and anyone advising you to do this would be written off as insane. The entire thrust of this thread is that you can have a more reliable system that is easier to reason about if you use specific constructs that each have less power, and non-distributed systems have the option to do this. Unstructured concurrency should be reserved exclusively for contexts where structured concurrency is impossible, which is what the actor model is for.

Re: Actors: A Model of Concurrent Computation [pdf] (1985)

#50

Post by ahoka »

eaurouge wrote: post #35
kibwen wrote: post #5

Please change the title to the original, "Actors: A Model Of Concurrent Computation In Distributed Systems". I'm not normally a stickler for HN's rule about title preservation, but in this case the "in distributed systems" part is crucial, because IMO the urge to use both the actor model (and its relative, CSP) in non-distributed systems solely in order to achieve concurrency has been a massive boondoggle and a huge…

Nurseries sound similar to run-till-completion schedulers [0]. > IMO the urge to use both the actor model (and its relative, CSP) in non-distributed systems solely in order to achieve concurrency has been a massive boondoggle Can't you model any concurrent non-distributed system as a concurrent distributed system? 0. https://en.wikipedia.org/wiki/Run-to-completion_scheduling

You can certainly make any simple problem complicated enough to need a complex solution. But that’s just bad engineering.
Post reply on HN