The Problem with Threads (2006) [pdf] • Hacker News Board

Re: The Problem with Threads (2006) [pdf]

#21

Post by gumby » Sat, May 05, 2018, 4:24 AM UTC

zzzcpan wrote: post #11

zbentley wrote: post #10

Earlier quoted context omitted.

My hunch: that modern programming often requires concurrent execution of software, but that most ways in which we have to model concurrency in code are at best hard to learn, and are frequently orders of magnitude harder to learn and use.

It would be the mainstream languages problem then or something. Concurrency with actor model is easier to learn and use than OOP, which many people seem to be able to use.

I find a lot (most?) OOP code I read is either spaghetti (with weird object interdependencies), diffuse (waay to many classes and subclasses so following the flow of computation becomes difficult) or both. It's a great tool, but perhaps harder than widely realized.

And concurrency is even harder, especially with the ever-popular "tweak until it parses/compiles, then ship" approach, or when many people are working on the same section of code.

The Hewitt Actor approach reduces independencies dramatically, at some cost for certain algorithms, and with added clarity for many others. And it scales somewhat automatically beyond one machine which is a big win these days.

My $0.02.

Re: The Problem with Threads (2006) [pdf]

#22

Post by dnautics » Sat, May 05, 2018, 5:13 AM UTC

toast0 wrote: post #20

jgtrosh wrote: post #4

This piece seems to have predicted a very active field in everyday software development since then. What are the alternative paradigms that have actually become common use? Coroutines, async/await, that's what I hear about online but what are others? I've seen people who touted zmq-communicating-processes with standard patterns as the solution to all problems, and I'm happy not to have to maintain the results. Have w…

At risk of being that guy , the actor model (ala Erlang) is pretty good at concurrency. If you're unfamiliar, it's basically no shared state, and communication with other actors (Erlang processes) by sending asynchronous messages to the other actor's message queue. The code for each actor is usually pretty small and easy to reason about. However, emergent behavior of the system, and ordering between messages from mul…

It's also relatively easy to implement async/await using actor primitives.

Re: The Problem with Threads (2006) [pdf]

#23

Post by ModernMech » Sat, May 05, 2018, 5:22 AM UTC

rectang wrote: post #2

I've always liked section 3 of this paper, specifically the concept that "infinite interleavings" make threads executing in parallel non-deterministic and difficult to reason about. That gets to the heart of why threaded programs are so prone to heisenbugs. "They make programs absurdly nondeterministic, and rely on programming style to constrain that nondeterminism to achieve deterministic aims." You can't write an i…

I identify with this bit from the paper

> To offer a third analogy, a folk deﬁnition of insanity is to do the same thing over and over again and to expect the results to be different. By this deﬁnition, we in fact require that programmers of multithreaded systems be insane. Were they sane, they could not understand their programs.

I actually had this exact notion when implementing pthreads for a course. I noted to myself "Gee, I keep doing the same thing and every time I get a different result... I must be insane according to the definition"

Re: The Problem with Threads (2006) [pdf]

#24

Post by acjohnson55 » Sat, May 05, 2018, 5:33 AM UTC

toast0 wrote: post #20

jgtrosh wrote: post #4

This piece seems to have predicted a very active field in everyday software development since then. What are the alternative paradigms that have actually become common use? Coroutines, async/await, that's what I hear about online but what are others? I've seen people who touted zmq-communicating-processes with standard patterns as the solution to all problems, and I'm happy not to have to maintain the results. Have w…

At risk of being that guy , the actor model (ala Erlang) is pretty good at concurrency. If you're unfamiliar, it's basically no shared state, and communication with other actors (Erlang processes) by sending asynchronous messages to the other actor's message queue. The code for each actor is usually pretty small and easy to reason about. However, emergent behavior of the system, and ordering between messages from mul…

The actor model is a great tool, but I think it's best looked at as a low level concurrency primitive. Most of the time, folks should be working with higher level constructs in conceptually simpler control flow paradigms like call-and-return (async/await) or streams.

Re: The Problem with Threads (2006) [pdf]

#25

Post by acjohnson55 » Sat, May 05, 2018, 5:36 AM UTC

barbegal wrote: post #8

jgtrosh wrote: post #4

This piece seems to have predicted a very active field in everyday software development since then. What are the alternative paradigms that have actually become common use? Coroutines, async/await, that's what I hear about online but what are others? I've seen people who touted zmq-communicating-processes with standard patterns as the solution to all problems, and I'm happy not to have to maintain the results. Have w…

Promises in javascript have become quite popular. Unfortunately, they're not understood very well so they aren't being used much in areas where they can improve the performance of javascript applications and instead are being used to reduce nested callbacks.

Really? At my company, promises have long since won the day. Now I'm trying to get people on async/await, which gets you like 90% of the way to the simplicity of synchronous code.

Re: The Problem with Threads (2006) [pdf]

#26

Post by true_religion » Sat, May 05, 2018, 5:47 AM UTC

acjohnson55 wrote: post #24

toast0 wrote: post #20

Earlier quoted context omitted.

At risk of being that guy , the actor model (ala Erlang) is pretty good at concurrency. If you're unfamiliar, it's basically no shared state, and communication with other actors (Erlang processes) by sending asynchronous messages to the other actor's message queue. The code for each actor is usually pretty small and easy to reason about. However, emergent behavior of the system, and ordering between messages from mul…

The actor model is a great tool, but I think it's best looked at as a low level concurrency primitive. Most of the time, folks should be working with higher level constructs in conceptually simpler control flow paradigms like call-and-return (async/await) or streams.

In Erlang, all those control flow paradigms exist in library form.

You are right about the actor model being a low-level choice, but its a choice that has to be made since the whole system revolves around allowing/disallowing shared state.

Re: The Problem with Threads (2006) [pdf]

#27

Post by chrisseaton » Sat, May 05, 2018, 9:00 AM UTC

toast0 wrote: post #20

jgtrosh wrote: post #4

This piece seems to have predicted a very active field in everyday software development since then. What are the alternative paradigms that have actually become common use? Coroutines, async/await, that's what I hear about online but what are others? I've seen people who touted zmq-communicating-processes with standard patterns as the solution to all problems, and I'm happy not to have to maintain the results. Have w…

At risk of being that guy , the actor model (ala Erlang) is pretty good at concurrency. If you're unfamiliar, it's basically no shared state, and communication with other actors (Erlang processes) by sending asynchronous messages to the other actor's message queue. The code for each actor is usually pretty small and easy to reason about. However, emergent behavior of the system, and ordering between messages from mul…

The actor model is very vulnerable to race conditions - that’s a big downside to it.

Re: The Problem with Threads (2006) [pdf]

#28

Post by chrisseaton » Sat, May 05, 2018, 9:11 AM UTC

zzzcpan wrote: post #11

zbentley wrote: post #10

Earlier quoted context omitted.

My hunch: that modern programming often requires concurrent execution of software, but that most ways in which we have to model concurrency in code are at best hard to learn, and are frequently orders of magnitude harder to learn and use.

It would be the mainstream languages problem then or something. Concurrency with actor model is easier to learn and use than OOP, which many people seem to be able to use.

The actor model is non-deterministic and doesn't solve all concurrency problems, such as creating fine-grained or irregular data parallelism. There isn't (and it may not be possible to have) one single solution to 'the concurrency problem'.

Re: The Problem with Threads (2006) [pdf]

#29

Post by zzzcpan » Sat, May 05, 2018, 11:03 AM UTC

chrisseaton wrote: post #28

zzzcpan wrote: post #11

Earlier quoted context omitted.

It would be the mainstream languages problem then or something. Concurrency with actor model is easier to learn and use than OOP, which many people seem to be able to use.

The actor model is non-deterministic and doesn't solve all concurrency problems, such as creating fine-grained or irregular data parallelism. There isn't (and it may not be possible to have) one single solution to 'the concurrency problem'.

Actor model is very deterministic, but it can model unbounded non-determinism, i.e. any concurrency problem. Including fine-grained and irregular data parallelism. It's up to the compiler to generate SIMD instructions out of it, if that's what you mean.

Re: The Problem with Threads (2006) [pdf]

#30

Post by chrisseaton » Sat, May 05, 2018, 11:23 AM UTC

zzzcpan wrote: post #29

chrisseaton wrote: post #28

Earlier quoted context omitted.

The actor model is non-deterministic and doesn't solve all concurrency problems, such as creating fine-grained or irregular data parallelism. There isn't (and it may not be possible to have) one single solution to 'the concurrency problem'.

Actor model is very deterministic, but it can model unbounded non-determinism, i.e. any concurrency problem. Including fine-grained and irregular data parallelism. It's up to the compiler to generate SIMD instructions out of it, if that's what you mean.

How co you argue it’s deterministic? If one actor asks two other actors to do a job and send the result back, those results come in a nondeterimistic order. That’s a race condition. It’s easy to write programs with bugs in them because of this.

Something like fork-join is deterministic because results come in a fixed order.

And for generating SIMD from actors? Or handling irregularity efficiently? I feel like you’re making the ‘sufficiently clever compiler’ argument.

We cannot currently efficiently solve all parallelism problems in practice using actors, and we don’t know how we would be able to.