6 ms·

Personally I prefer message passing (over pipes). Shared memory (be it shm/heap in same process) with associated mutexes, semaphores, locks and the like is a r

by csmuk 13y ago

Personally I prefer message passing (over pipes). Shared memory (be it shm/heap in same process) with associated mutexes, semaphores, locks and the like is a right pain to get right without introducing race conditions, deadlocks etc. Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet.

AndrewDucker 13y ago
This is why Mozilla are investing heavily in Rust, so that they can use its semantics to share memory in a safe way.
- pjmlp 13y ago
  Yes, I look forward to the day memory unsafe languages are only part of legacy systems.
rdtsc 13y ago
> Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet. But is also has shared heaps by default. So you still have to rely on everyone being an "adult". I wish shared heaps would have been a specially enabled feature not the default. But I guess the language was position to compete with C++ and Java and isolated heaps would have provided a performance decrease in benchmarks -- and thus people's willingness to adopt it. For large concurrent systems, safety and fault tolerance often leads to their failure but it is kind of hard to encode that in a quick benchmark to impress people. Here are a few languages/systems with default isolated heap runtimes between concurrency units: Dart's isolates, Erlang's processes, Nimrod's threads, Web Workers in modern browsers. Anyone know of more?
- pjmlp 13y ago
  In D, by default global data is actually thread local. You need to explicitly enable sharing.
  - pcwalton 13y ago
    But you can send shared memory between threads and race on it, presumably?
    - pjmlp 13y ago
      Yes, but you need to explicitly request it http://dlang.org/migrate-to-shared.html http://dlang.org/migrate-to-shared.html http://www.informit.com/articles/printerfriendly.aspx?p=1609144 http://www.informit.com/articles/printerfriendly.aspx?p=1609...
- csmuk 13y ago
  My C code doesn't share heaps. Strict privsep design meaning one heap per process and no threads in favour of "select".
  - rdtsc 13y ago
    Well, OS processes are the obvious solution. I was asking about languages/runtimes that feature that as a default. > and no threads in favour of "select". Not sure why you mentioned that. Callback chains can create concurrency contexts (callback chains) that can interfere with each other, much like multiple threads would. It would have a much higher granularity but you are not out of the woods.
    - csmuk 13y ago
      Only because I usually end up knocking up network servers. That is true but you only have one thread to synchronise so mutexes and locks are vastly simplified.
- kibwen 13y ago
  > Anyone know of more? Rust's "tasks" feature isolated memory, and, thanks to the magic of linear types, passing data from one to another is both statically-guaranteed to be safe and is never more expensive than the cost of copying a pointer.
  - dbaupp 13y ago
    > is never more expensive than the cost of copying a pointer Well, if you're passing something that is pointer size, yes. But say, `chan.send([0u8, .. 1_000_000])` will do at least one 1 MB memcpy to load that into the stream, and a 1 MB memcpy to load it out of it when `.recv()` is called.
- jerf 13y ago
  "I wish shared heaps would have been a specially enabled feature not the default." I hope to someday see the language at least do the opposite, have a specially-declarable "isolated" goroutine. In theory, the compiler ought to be able to analyze a goroutine, determine that it shares no data at startup with another process (i.e., nothing in a closure or something), determine that it only communicates via value-passing channels (which courtesy of my previous restriction, can be analyzed by simply looking at what channels are passed in at startup time, and some analysis of the types of the channels), and thus guarantee that at least this goroutine is fully isolated. Pervasive usage of the new keyword I'm hypothesizing would allow a diligent programmer to recover most of the isolation advantages without having to rewrite Go entirely. It also ought to enable some other optimizations against these guaranteed-isolated goroutines, the biggest of which is that they no longer need to participate in a global stop-the-world GC, both in that they can continue running while that is occurring and that they also relieve the global GC from the task of scanning over them. (In fact all the analysis ought to itself be fully automateable, and the user shouldn't have to declare it; I'd want them to still have the option to make a declaration so the compiler can tell them if they screwed up, though. I don't like such critical functionality being behind an opaque optimizer.) But this certainly won't happen soon; there's a large enough list of stuff that comes before that.
  - pcwalton 13y ago
    > determine that it only communicates via value-passing channels (which courtesy of my previous restriction, can be analyzed by simply looking at what channels are passed in at startup time, and some analysis of the types of the channels), That would preclude sending interfaces over channels (along with any other existential or mutable reference type), because the type system doesn't know whether the interface is closing over shared state. Not being able to send interfaces over channels would mean that channels would be restricted to only one kind of type, because Go doesn't have discriminated unions so interfaces are the only way to perform type-switch. Those goroutines would be so restricted as to be almost useless. You cannot just bolt isolation on after the fact. You must design your language for it from the start. That said, Go's race detector is very good and it's awesome that they focused on getting first-class support for runtime race detection so early.
- pmarin 13y ago
  >Here are a few languages/systems with default isolated heap runtimes between concurrency units: Dart's isolates, Erlang's processes, Nimrod's threads, Web Workers in modern browsers. Anyone know of more? Tcl runs an interpreter per thread and communicate each other using message passing.
nly 13y ago
Going multiprocess and using IPC doesn't intrinsically eliminate any of the tricky concurrency challenges with multi-threading. Neither do coroutines (goroutines). When you have multiple processes talking to another then, unless all your RPCs are completely stateless, you still need to orchestrate synchronisation in some form. There's also the problem that in 2013 we still don't really know how to do IPC/RPCs really well, and doing so portably is hard (Notice Mozilla are writing their own from scratch) It's all very well new languages coming along and solving the trivial stuff (setting up message queues, isolating memory) but very few of them do anything to solve the real problems.
- pjmlp 13y ago
  True, but it does help making the applications more resilient specially if they are stateless. The "let it crash" model from Erlang and micro-kernels. Still you are right, we are far from having an acceptable solution that we could apply everywhere, so to say.
- pcwalton 13y ago
  > It's all very well new languages coming along and solving the trivial stuff (setting up message queues, isolating memory) but very few of them do anything to solve the real problems. I think that Rust makes a lot of effort to move things in the right direction. In Rust you can share memory, but unless you are in the unsafe sublanguage (which is clearly marked) the type system restricts you to one of: (1) copying messages; (2) transferring ownership of a message so that the original thread cannot race on it; (3) sharing immutable memory only; (4) taking a lock before accessing mutable data. We've seen huge engineering benefits from this: making parts of Servo thread-safe has been simply a matter of running the compiler repeatedly and letting the error messages tell us where to insert the locks; when it compiles we know the data races are gone. (You can still deadlock though.)

by csmuk 13y ago

AndrewDucker 13y ago

This is why Mozilla are investing heavily in Rust, so that they can use its semantics to share memory in a safe way.

pjmlp 13y ago
Yes, I look forward to the day memory unsafe languages are only part of legacy systems.

rdtsc 13y ago

> Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet. But is also has shared heaps by default. So you still have to rely on everyone being an "adult". I wish shared heaps would have been a specially enabled feature not the default. But I guess the language was position to compete with C++ and Java and isolated heaps would have provided a performance decrease in benchmarks -- and thus people's willingness to adopt it. For large concurrent systems, safety and fault tolerance often leads to their failure but it is kind of hard to encode that in a quick benchmark to impress people. Here are a few languages/systems with default isolated heap runtimes between concurrency units: Dart's isolates, Erlang's processes, Nimrod's threads, Web Workers in modern browsers. Anyone know of more?

pjmlp 13y ago
In D, by default global data is actually thread local. You need to explicitly enable sharing.
- pcwalton 13y ago
  But you can send shared memory between threads and race on it, presumably?
  - pjmlp 13y ago
    Yes, but you need to explicitly request it http://dlang.org/migrate-to-shared.html http://dlang.org/migrate-to-shared.html http://www.informit.com/articles/printerfriendly.aspx?p=1609144 http://www.informit.com/articles/printerfriendly.aspx?p=1609...
csmuk 13y ago
My C code doesn't share heaps. Strict privsep design meaning one heap per process and no threads in favour of "select".
- rdtsc 13y ago
  Well, OS processes are the obvious solution. I was asking about languages/runtimes that feature that as a default. > and no threads in favour of "select". Not sure why you mentioned that. Callback chains can create concurrency contexts (callback chains) that can interfere with each other, much like multiple threads would. It would have a much higher granularity but you are not out of the woods.
  - csmuk 13y ago
    Only because I usually end up knocking up network servers. That is true but you only have one thread to synchronise so mutexes and locks are vastly simplified.
kibwen 13y ago
> Anyone know of more? Rust's "tasks" feature isolated memory, and, thanks to the magic of linear types, passing data from one to another is both statically-guaranteed to be safe and is never more expensive than the cost of copying a pointer.
- dbaupp 13y ago
  > is never more expensive than the cost of copying a pointer Well, if you're passing something that is pointer size, yes. But say, `chan.send([0u8, .. 1_000_000])` will do at least one 1 MB memcpy to load that into the stream, and a 1 MB memcpy to load it out of it when `.recv()` is called.
jerf 13y ago
"I wish shared heaps would have been a specially enabled feature not the default." I hope to someday see the language at least do the opposite, have a specially-declarable "isolated" goroutine. In theory, the compiler ought to be able to analyze a goroutine, determine that it shares no data at startup with another process (i.e., nothing in a closure or something), determine that it only communicates via value-passing channels (which courtesy of my previous restriction, can be analyzed by simply looking at what channels are passed in at startup time, and some analysis of the types of the channels), and thus guarantee that at least this goroutine is fully isolated. Pervasive usage of the new keyword I'm hypothesizing would allow a diligent programmer to recover most of the isolation advantages without having to rewrite Go entirely. It also ought to enable some other optimizations against these guaranteed-isolated goroutines, the biggest of which is that they no longer need to participate in a global stop-the-world GC, both in that they can continue running while that is occurring and that they also relieve the global GC from the task of scanning over them. (In fact all the analysis ought to itself be fully automateable, and the user shouldn't have to declare it; I'd want them to still have the option to make a declaration so the compiler can tell them if they screwed up, though. I don't like such critical functionality being behind an opaque optimizer.) But this certainly won't happen soon; there's a large enough list of stuff that comes before that.
- pcwalton 13y ago
  > determine that it only communicates via value-passing channels (which courtesy of my previous restriction, can be analyzed by simply looking at what channels are passed in at startup time, and some analysis of the types of the channels), That would preclude sending interfaces over channels (along with any other existential or mutable reference type), because the type system doesn't know whether the interface is closing over shared state. Not being able to send interfaces over channels would mean that channels would be restricted to only one kind of type, because Go doesn't have discriminated unions so interfaces are the only way to perform type-switch. Those goroutines would be so restricted as to be almost useless. You cannot just bolt isolation on after the fact. You must design your language for it from the start. That said, Go's race detector is very good and it's awesome that they focused on getting first-class support for runtime race detection so early.
pmarin 13y ago
>Here are a few languages/systems with default isolated heap runtimes between concurrency units: Dart's isolates, Erlang's processes, Nimrod's threads, Web Workers in modern browsers. Anyone know of more? Tcl runs an interpreter per thread and communicate each other using message passing.

nly 13y ago

Going multiprocess and using IPC doesn't intrinsically eliminate any of the tricky concurrency challenges with multi-threading. Neither do coroutines (goroutines). When you have multiple processes talking to another then, unless all your RPCs are completely stateless, you still need to orchestrate synchronisation in some form. There's also the problem that in 2013 we still don't really know how to do IPC/RPCs really well, and doing so portably is hard (Notice Mozilla are writing their own from scratch) It's all very well new languages coming along and solving the trivial stuff (setting up message queues, isolating memory) but very few of them do anything to solve the real problems.

pjmlp 13y ago
True, but it does help making the applications more resilient specially if they are stateless. The "let it crash" model from Erlang and micro-kernels. Still you are right, we are far from having an acceptable solution that we could apply everywhere, so to say.
pcwalton 13y ago
> It's all very well new languages coming along and solving the trivial stuff (setting up message queues, isolating memory) but very few of them do anything to solve the real problems. I think that Rust makes a lot of effort to move things in the right direction. In Rust you can share memory, but unless you are in the unsafe sublanguage (which is clearly marked) the type system restricts you to one of: (1) copying messages; (2) transferring ownership of a message so that the original thread cannot race on it; (3) sharing immutable memory only; (4) taking a lock before accessing mutable data. We've seen huge engineering benefits from this: making parts of Servo thread-safe has been simply a matter of running the compiler repeatedly and letting the error messages tell us where to insert the locks; when it compiles we know the data races are gone. (You can still deadlock though.)