2 ms·

"Just m:n threads" is serious downplaying, most operating systems and languages that had that retired it eventually. The go implementation of goroutines is real

"Just m:n threads" is serious downplaying, most operating systems and languages that had that retired it eventually. The go implementation of goroutines is really really good.

felixgallo 3y ago
m:n threads is the basis of every non-embedded operating system, so I wouldn't say that model's been retired or is even under plausible threat. Loom and such are refitting Java with it, for example. The only problem with m:n is that it requires a thread-aware runtime to fully implement the abstraction.
- klooney 3y ago
  Linux (or glibc I guess) and Solaris both rolled back their m:n threading implementations over a decade ago. It's a really hard problem, and you kind of need to own the whole stack. The only other system with a comparable implementation is Erlang.
  - felixgallo 3y ago
    linux is m:n today and always has been, so I guess I don't know what you're talking about.
dekhn 3y ago
I'm not saying their implementation isn't good, it is good. And probably message-passing is the right concurrency primitive to expose at a language level for people who want to take advantage of multi-core machines running concurrent code. I'm not downplaying anything; I'm expressing merely that with a title like "Goroutines: The concurrency model we all..." makes it sounds like go invented something new, but afaict, they're just a well-engineered implemention of already well-understood concurrency principles.
- zwieback 3y ago
  100%, as I was reading the article I was remembering the different types of concurrency mechanisms I've used and I think it's helpful to have something like goroutines as a first-class language feature but it's not new in any way. When it comes to concurrency I think it's good to go through the curriculum: - main loop + interrupt handler - processes (fork) - multi-core concerns - threads (now is a good time to learn about mutex, semaphore, critical section) - lightweight threads (fiber, coroutines, green threads): learn how they are different - async/await statemachines written by the compiler Ok, now we have the background info to make wise choices and call things by their generalized names to avoid holy wars.

"Just m:n threads" is serious downplaying, most operating systems and languages that had that retired it eventually. The go implementation of goroutines is really really good.

felixgallo 3y ago

m:n threads is the basis of every non-embedded operating system, so I wouldn't say that model's been retired or is even under plausible threat. Loom and such are refitting Java with it, for example. The only problem with m:n is that it requires a thread-aware runtime to fully implement the abstraction.

klooney 3y ago
Linux (or glibc I guess) and Solaris both rolled back their m:n threading implementations over a decade ago. It's a really hard problem, and you kind of need to own the whole stack. The only other system with a comparable implementation is Erlang.
- felixgallo 3y ago
  linux is m:n today and always has been, so I guess I don't know what you're talking about.

dekhn 3y ago

I'm not saying their implementation isn't good, it is good. And probably message-passing is the right concurrency primitive to expose at a language level for people who want to take advantage of multi-core machines running concurrent code. I'm not downplaying anything; I'm expressing merely that with a title like "Goroutines: The concurrency model we all..." makes it sounds like go invented something new, but afaict, they're just a well-engineered implemention of already well-understood concurrency principles.

zwieback 3y ago
100%, as I was reading the article I was remembering the different types of concurrency mechanisms I've used and I think it's helpful to have something like goroutines as a first-class language feature but it's not new in any way. When it comes to concurrency I think it's good to go through the curriculum: - main loop + interrupt handler - processes (fork) - multi-core concerns - threads (now is a good time to learn about mutex, semaphore, critical section) - lightweight threads (fiber, coroutines, green threads): learn how they are different - async/await statemachines written by the compiler Ok, now we have the background info to make wise choices and call things by their generalized names to avoid holy wars.