4 ms·

the concurrency safety model (Send+Sync), though that might be old too Smalltalk has had that since the early 1980s

Manishearth 10y ago
Interesting, thanks!
steveklabnik 10y ago
I'd like to read more about this, do you have a recommendation of where I can look? I have a basic fluency in Smalltalk, but it's been a while.
gpderetta 10y ago
that's interesting, AFAIK smaltalk is fully dynamic and has no compile-time type checking, so how would it statically enforce the equivalent of Send and Sync constraints?
- stcredzero 10y ago
  In most implementations, Smalltalk is compiled to bytecode, and uses late binding. It's usually run on a JIT. how would it statically enforce the equivalent of Send and Sync constraints? In some Smalltalks, normal execution is synchronous. Many of them also use read and write boundaries for various purposes. The former gives you Send and Sync constraints for free. The latter can be used in difficult edge cases. (Like when you're calling out to the OS.)
  - Manishearth 10y ago
    > The former gives you Send and Sync constraints for free. Uh, no, it gives you thread safety for free. When my comment was talking about Send and Sync I was talking about the specific way Rust's typesystem enforces thread safety. I'm not saying that other languages don't, I'm saying that Rust's method of enforcing it might be one of the few unique things it does
dbaupp 10y ago
Like steveklabnik, I'm extremely curious to hear more about how Smalltalk's concurrency model is just like Rust's. The latter is a fairly flexible model to defend against data races (which seems to be a concept only really formalised in the late 80s) that puts most of the power in the programmer's hands (i.e. no need for compiler-inserted locks on every object, etc.) that comes from a finely balanced combination of the trait system and the manner in which Rust controls mutation. It would be great to see how other languages have achieved a similar balance, and my impression is that Smalltalk (and like most languages) does not put nearly as much effort into controlling mutability, but maybe I'm wrong. Could you post some links/a description that explores how Smalltalk achieves a similar level of safety?
- nickpsecurity 10y ago
  "which seems to be a concept only really formalised in the late 80s" http://brinch-hansen.net/papers/1975a.pdf http://brinch-hansen.net/papers/1975a.pdf http://brinch-hansen.net/papers/ http://brinch-hansen.net/papers/ His first, concurrent OS was RC 4000 in 1969. It had many mechanisms in place. He got the key parts of the safety problem figured out by 1972. His language to handle much of it statically at compile-time was done in 1975. His Boss 2 system same year used coroutines + similar concepts to run 100 activities at a time with a proof of deadlock freedom. Finally, he used Concurrent Pascal to implement Solo system which ran its processes safely without using physical, memory protection. These summaries came from "Evolution of Operating Systems" on 2nd link. So, the stuff was well-established by the mid-70's with operating systems using it in production. Just ignored by mainstream like a lot of good stuff for various reasons. ;)
  - dbaupp 10y ago
    I don't have time to read it in full right now, but a quick glance over that paper doesn't show any formalisation of data races, which is specifically what that parenthetical is about, not just general "concurrency safety". Having a detailed description of concept seems important because Rust is fairly precise in what it defends against, possibly giving the programmer more flexibility and power than in a system that attempts to solve many problems (but of course giving them less assistance when writing something that fits within the rules of the more defensive languages). Of course, it's possible that a language "accidentally" solves that problem without it having been formalised, it just seems less likely.
pcwalton 10y ago
Smalltalk is dynamically typed. How can it have a static type system feature?
- Manishearth 10y ago
  (Yeah, just to clarify, in my comment above, I'm talking about systems similar to Rust's specific system for enforcing thread safety; not arbitrary systems that enforce thread safety in a different way)
stcredzero 10y ago
Smalltalk has had that since the early 1980s That really depends on which Smalltalk you're talking about, I think. Various implementations really had different concurrency models. Some implementations used native OS threads. Others ran synchronously "inside the image" but spawned threads to interact with the OS.

Interesting, thanks!

I'd like to read more about this, do you have a recommendation of where I can look? I have a basic fluency in Smalltalk, but it's been a while.

gpderetta 10y ago

that's interesting, AFAIK smaltalk is fully dynamic and has no compile-time type checking, so how would it statically enforce the equivalent of Send and Sync constraints?

stcredzero 10y ago
In most implementations, Smalltalk is compiled to bytecode, and uses late binding. It's usually run on a JIT. how would it statically enforce the equivalent of Send and Sync constraints? In some Smalltalks, normal execution is synchronous. Many of them also use read and write boundaries for various purposes. The former gives you Send and Sync constraints for free. The latter can be used in difficult edge cases. (Like when you're calling out to the OS.)
- Manishearth 10y ago
  > The former gives you Send and Sync constraints for free. Uh, no, it gives you thread safety for free. When my comment was talking about Send and Sync I was talking about the specific way Rust's typesystem enforces thread safety. I'm not saying that other languages don't, I'm saying that Rust's method of enforcing it might be one of the few unique things it does

dbaupp 10y ago

Like steveklabnik, I'm extremely curious to hear more about how Smalltalk's concurrency model is just like Rust's. The latter is a fairly flexible model to defend against data races (which seems to be a concept only really formalised in the late 80s) that puts most of the power in the programmer's hands (i.e. no need for compiler-inserted locks on every object, etc.) that comes from a finely balanced combination of the trait system and the manner in which Rust controls mutation. It would be great to see how other languages have achieved a similar balance, and my impression is that Smalltalk (and like most languages) does not put nearly as much effort into controlling mutability, but maybe I'm wrong. Could you post some links/a description that explores how Smalltalk achieves a similar level of safety?

nickpsecurity 10y ago
"which seems to be a concept only really formalised in the late 80s" http://brinch-hansen.net/papers/1975a.pdf http://brinch-hansen.net/papers/1975a.pdf http://brinch-hansen.net/papers/ http://brinch-hansen.net/papers/ His first, concurrent OS was RC 4000 in 1969. It had many mechanisms in place. He got the key parts of the safety problem figured out by 1972. His language to handle much of it statically at compile-time was done in 1975. His Boss 2 system same year used coroutines + similar concepts to run 100 activities at a time with a proof of deadlock freedom. Finally, he used Concurrent Pascal to implement Solo system which ran its processes safely without using physical, memory protection. These summaries came from "Evolution of Operating Systems" on 2nd link. So, the stuff was well-established by the mid-70's with operating systems using it in production. Just ignored by mainstream like a lot of good stuff for various reasons. ;)
- dbaupp 10y ago
  I don't have time to read it in full right now, but a quick glance over that paper doesn't show any formalisation of data races, which is specifically what that parenthetical is about, not just general "concurrency safety". Having a detailed description of concept seems important because Rust is fairly precise in what it defends against, possibly giving the programmer more flexibility and power than in a system that attempts to solve many problems (but of course giving them less assistance when writing something that fits within the rules of the more defensive languages). Of course, it's possible that a language "accidentally" solves that problem without it having been formalised, it just seems less likely.

pcwalton 10y ago

Smalltalk is dynamically typed. How can it have a static type system feature?

Manishearth 10y ago
(Yeah, just to clarify, in my comment above, I'm talking about systems similar to Rust's specific system for enforcing thread safety; not arbitrary systems that enforce thread safety in a different way)

stcredzero 10y ago

Smalltalk has had that since the early 1980s That really depends on which Smalltalk you're talking about, I think. Various implementations really had different concurrency models. Some implementations used native OS threads. Others ran synchronously "inside the image" but spawned threads to interact with the OS.