4 ms·

great to see this coming from non-functional language folks (after years of banging out about it in Haskell land -http://ghcmutterings.wordpress.com/2009/10/06/

by dons 15y ago

great to see this coming from non-functional language folks (after years of banging out about it in Haskell land -http://ghcmutterings.wordpress.com/2009/10/06/parallelism-concurrency/ http://ghcmutterings.wordpress.com/2009/10/06/parallelism-co... ) Of course, concurrency is not the end of things. Deterministic parallelism is a beautiful model for making things faster, easily. So you need that in your language somehow too. Edit: there's a cite for Bob Harper on this, http://existentialtype.wordpress.com/2011/03/17/parallelism-is-not-concurrency/ http://existentialtype.wordpress.com/2011/03/17/parallelism-... , which was a bit later than Simon's post.

mdwrigh2 15y ago
Simon commented on this talk on G+: https://plus.google.com/107890464054636586545/posts/dVowddBT8AW https://plus.google.com/107890464054636586545/posts/dVowddBT...
bascule 15y ago
The process isolation model that CSP provides is generally useful within languages with mutable state. In particular, the Kilim library for Java uses "microthreads" (similar to goroutines) plus a linear ownership transfer system such that only one microthread owns a given object/object graph at a time, preventing concurrent state mutation while still providing mutable state. Sending an object from one Kilim task to another transfers ownership, and thus messages become the mechanism by which state is isolated at the process level. Mutable state can be safe too. You just need the proper abstractions.
- Peaker 15y ago
  This sounds like runtime safety, not compile-time safety. Otherwise, how can you avoid aliasing that modifies the object for which you lost ownership? Immutable state gives you compile-time-safety. I think when people say "shared mutable state is unsafe", at least some of them are referring to compile-time safety. If it compiles, these kinds of concurrency-related bugs are impossible.
  - wmf 15y ago
    At least in Rust, unique pointers should be guaranteed by the compiler so when you pass one to another thread you know there's no aliasing.
  - riffraff 15y ago
    AFAIR kilim guarantees statically checked safety, exactly because "messages" that can be sent across actor borders have guaranteed properties of being aliaseable^mutable.

by dons 15y ago

mdwrigh2 15y ago

Simon commented on this talk on G+: https://plus.google.com/107890464054636586545/posts/dVowddBT8AW https://plus.google.com/107890464054636586545/posts/dVowddBT...

bascule 15y ago

The process isolation model that CSP provides is generally useful within languages with mutable state. In particular, the Kilim library for Java uses "microthreads" (similar to goroutines) plus a linear ownership transfer system such that only one microthread owns a given object/object graph at a time, preventing concurrent state mutation while still providing mutable state. Sending an object from one Kilim task to another transfers ownership, and thus messages become the mechanism by which state is isolated at the process level. Mutable state can be safe too. You just need the proper abstractions.

Peaker 15y ago
This sounds like runtime safety, not compile-time safety. Otherwise, how can you avoid aliasing that modifies the object for which you lost ownership? Immutable state gives you compile-time-safety. I think when people say "shared mutable state is unsafe", at least some of them are referring to compile-time safety. If it compiles, these kinds of concurrency-related bugs are impossible.
- wmf 15y ago
  At least in Rust, unique pointers should be guaranteed by the compiler so when you pass one to another thread you know there's no aliasing.
- riffraff 15y ago
  AFAIR kilim guarantees statically checked safety, exactly because "messages" that can be sent across actor borders have guaranteed properties of being aliaseable^mutable.