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

61–70 of 80 posts

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

#61

Post by kibwen »

crustycoder wrote: post #32
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…

Eh? I've written a non-distributed app that uses the Actor model and it's been very successful. It concurrently collects data from hundreds of REST endpoints, a typical run may make 500,000 REST requests, with 250 actors making simultaneous requests - I've tested with 1,000 but that tends to pound the REST servers into the ground. Any failed requests are re-queued. The requests aren't independent, request type C may…

> That "nurseries" link is way TL;DR

Please read and understand that blog post, I promise it's worth your time.

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

#62

Post by felixgallo »

janderland wrote: post #58
kibwen wrote: post #49

Earlier quoted context omitted.

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

Don’t Erlang/Elixir model all concurrency as actors, to some level of success. I was under the impression that it allows for quite a bit of deployment flexibility. Actors are addressed in the same way whether they’re on the same machine or not.

yes, to huge levels of success. It's not clear what kibwen is going on about, but local + remote actor concurrency transparency, while not without its complications, comes with massive development and deployment wins.

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

#63

Post by eaurouge »

kibwen wrote: post #59
eaurouge wrote: post #54

Earlier quoted context omitted.

The point I was trying to make is that you can apply the actor model to any system of isolated processes. Whether the isolated processes live on a distributed system of networked computers or on the same computer is an implementation detail. The critical issue is that each actor should own and mutate its own state. Whether all actors run on the same thread or on separate threads is also an implementation detail. For…

> Easier to reason about, sure, fine. Your earlier comment claims the actor model is a dead end in non-distributed systems. If you have two ways of structuring something, and the worse way is so predominant that it obscures even the existence of the better way, that's a dead end in my book. In the pre-structured-programming days when people had to fight tooth and nail to get people to acknowledge the value of `if` an…

I read the article you referenced. It's based on, and described wrt, Python's `async with` (so quite a few layers of abstraction), so I can't say with certainty how it's implemented. But, as I noted earlier, it isn't really that different from a run-till-completion task scheduler and is not particularly novel or interesting, imo.

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

#64

Post by teleforce »

michaelsbradley wrote: post #4

May be of interest: Pony Language is designed from the ground up to support the Actor model. https://www.ponylang.io/

D language is also supporting actor model in the standard library for its concurrent, parallel and distributed programming [1].

[1] D (programming language):

https://en.wikipedia.org/wiki/D_(programming_language)

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

#65

Post by c0balt »

pedroza_alex wrote: post #11
esafak wrote: post #2

A more legible version: https://dspace.mit.edu/handle/1721.1/6952 https://en.wikipedia.org/wiki/Gul_Agha_(computer_scientist)

The first link returns a 403.

Both seem to be accessible from Germany. Maybe a geoblock?

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

#66

Post by PaulHoule »

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…

It is endemic to the JVM world that people try various forms of snake oil concurrency inside an address space like actors and the original synchronized model when java.util.concurrent and Executors are "all you need."

It was a theme in part of my career to pick up something written in Scala that used actors that (1) didn't always get the same answer and (2) didn't use all the CPU cores and struggling for days to get it working right with actors then taking 20 minutes to rewrite it using Executors and getting it to work the first time and always work thereafter.

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

#67

Post by rurban »

ahoka wrote: post #48
rurban wrote: post #30

Earlier quoted context omitted.

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.

A bad one, yes. But it was esp. invented to prevent the mutual exclusion problem. And good actor systems do so.

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

#68

Post by k_g_b_ »

eaurouge wrote: post #54
kibwen wrote: post #49

Earlier quoted context omitted.

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

The point I was trying to make is that you can apply the actor model to any system of isolated processes. Whether the isolated processes live on a distributed system of networked computers or on the same computer is an implementation detail. The critical issue is that each actor should own and mutate its own state. Whether all actors run on the same thread or on separate threads is also an implementation detail. For…

Structured concurrency is also a Kotlin thing https://kotlinlang.org/docs/coroutines-basics.html#coroutine... and a Python thing https://vorpus.org/blog/notes-on-structured-concurrency-or-g... and before that it was a C thing https://sustrik.github.io/250bpm/blog:71/

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

#69

Post by crustycoder »

kibwen wrote: post #61
crustycoder wrote: post #32

Earlier quoted context omitted.

Eh? I've written a non-distributed app that uses the Actor model and it's been very successful. It concurrently collects data from hundreds of REST endpoints, a typical run may make 500,000 REST requests, with 250 actors making simultaneous requests - I've tested with 1,000 but that tends to pound the REST servers into the ground. Any failed requests are re-queued. The requests aren't independent, request type C may…

> That "nurseries" link is way TL;DR Please read and understand that blog post, I promise it's worth your time.

Um, no I won't and no it won't. I have no time for tub-thumping.

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

#70

Post by lmm »

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.

> Actors can be made to do structured concurrency as long as you allow actors to wait for responses from other actors

At which point they're very much not actors any more. You've lost the deadlock avoidance, you can't do the `become`-based stuff that looks so great in small demos. At that point what are you gaining from using actors at all?

Post reply on HN