| |||||||||||||
CoroutinesCoroutinesPosted May 8, 2012 17:46 UTC (Tue) by juliank (subscriber, #45896)In reply to: Coroutines by geertj Parent article: nPth - The new GNU portable threads library
Threads don't need locking if you only use message passing between threads, and this should be the primary way to do such things.
(Log in to post comments)
Coroutines Posted May 8, 2012 17:59 UTC (Tue) by fuhchee (subscriber, #40059) [Link]
"don't need locking if you only use message passing between"
Despite that advantage, pure message-passing-based concurrency hasn't taken the CS world by storm.
Coroutines Posted May 8, 2012 18:50 UTC (Tue) by juliank (subscriber, #45896) [Link]
Not yet, but work is happening, for example in Go (Go actually uses a hybrid co-routine/thread architecture, but this does not matter); and other stuff continuing those Plan 9 concepts.
Coroutines Posted May 8, 2012 19:07 UTC (Tue) by wahern (subscriber, #37304) [Link]
Go is based on Limbo, not Plan 9. It's like the difference between Awk and Unix. I mention it because Plan 9 was influential is so many other ways. The recent C11 standard has many features which originated (I believe) with Plan 9's C extensions. UTF-8 was first used in Plan 9. Modern /proc, I believe, is descended from Plan 9. And nothing about Plan 9 dictates or even strongly suggests a message-based multi-threaded language design.
Coroutines Posted May 8, 2012 19:37 UTC (Tue) by juliank (subscriber, #45896) [Link]
I'd say that Go is actually closer to Alef then Limbo. And it really is Plan 9 derived in some way. Not only the languages such as Alef, and later Limbo, but there's also a C library called libtask that implements the channel/thread mechanism (using user threads, Plan 9 doesn't seem to do kernel threads).
Coroutines Posted May 8, 2012 20:18 UTC (Tue) by wahern (subscriber, #37304) [Link]
The design behind Plan 9 predates both Alef and the threading library. Lots of fruitful things were developed on Plan 9, and some folded back into the low-level systems. libtask was developed for Alef and only made available to run-of-the-mill C application later. According to Wikipedia, Plan 9 began in the mid '80s, and libtask was folded into the mix in 2000, two years before the project officially ended.
Limbo succeeded Alef, and Go seems to have succeeded Limbo. But I'll admit this is all just largely opinion.
But more to the point, Plan 9 never touted intraprocess message passing. If you read any of the papers, when they talked about parallelism they spoke about their rfork() system call (which may have inspired Linux' clone syscall; OpenBSD's rfork is clearly derivative of Plan 9). Alef, and later Limbo, was where all the experimentation into messaging passing went, and I think my comparison to Awk v. Unix is apt. To see where I'm coming from, just read their own description and emphasis: http://www.cs.bell-labs.com/sys/doc/9.html
Coroutines Posted May 9, 2012 16:39 UTC (Wed) by hanwen (subscriber, #4329) [Link]
According to the spec Go, but you still need locking between goroutines; an implementation which uses 1 thread per go-routine is conforming.
Coroutines Posted May 9, 2012 18:51 UTC (Wed) by juliank (subscriber, #45896) [Link]
Goroutines are transparently moved across threads, and work correctly, as long as you do not access shared memory (which you should not do).
Coroutines Posted May 11, 2012 13:43 UTC (Fri) by hanwen (subscriber, #4329) [Link]
well, you need synchronization. Either channels or locks. A coroutine which does not synchronize at all may be optimized to not run at all, according to the spec.
Coroutines Posted May 8, 2012 20:54 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Not a lot of applications require massively parallel computations.
In niche areas Erlang (built on message passing) is quite popular.
Coroutines Posted May 8, 2012 19:03 UTC (Tue) by endecotp (guest, #36428) [Link]
> Threads don't need locking if you only use message
> passing between threads
How do you implement your message passing? Most likely it needs some form of locking internally.
I would express it this way: don't try to implement your multi-threaded application using ad-hoc locking / synchronisation. Instead put all of the locking into some concurrency building blocks and restrict your inter-thread communication to only those building blocks. Message passing is one possible set of building blocks, but there are others.
|
|||||||||||||