13 ms·

> It’s very difficult to write multithreaded code, which is the only way to exploit the abilities of modern machines. QED? Really? I'm not so sure I trust the

> It’s very difficult to write multithreaded code, which is the only way to exploit the abilities of modern machines. QED? Really? I'm not so sure I trust the author to give rust fair treatment anymore. An operating system that does multithreading is not the same as a modern machine. Edit: Any brave down voters want to explain why? Threads are a way to model concurrency. There are other ways.

AnimalMuppet 11y ago
I'm not the downvoter. But you may be getting the downvotes because you're throwing out snark ("Really? I'm not so sure I trust the author to give rust fair treatment anymore") and dogmatic statements ("An operating system that does multithreading is not the same as a modern machine") with no explanation or justification. It sounds like you're expecting us to agree with your statement as self-evident, or be relegated to the ranks of it ignorant if we don't. That is, it sounds like a one-up game ("I'm smarter/better informed than you"), rather than real conversation. If you don't want to come across that way, give us some explanation of what you're thinking and why. Give us some evidence that your statement is true. Something besides just dogmatic assertions that you're right and the author of the article is stupid and/or biased. Moving on... In the context of the OS, multithreading (or something essentially equivalent) is the only way to exploit the abilities of "modern" machines. But "modern" doesn't mean very modern (at least, as I understand it). It means the difference between MSDOS and Windows: "Windows is multitasking, whereas DOS... DOS is serially multitasking." (I don't recall who said that, but it was brilliant.) Without this capability, you're only running one program at a time. Now, I don't care if you implement this as "theads" or something else, but if you don't have it, your OS is pretty much worthless, and has been since about 1990.
- 0xdeadbeefbabe 11y ago
  Thanks for the advice on dogmatism coupled with the statement about having a worthless OS since 1990. > In the context of the OS, multithreading (or something essentially equivalent) is the only way to exploit the abilities of "modern" machines. I noticed that you qualified multithreading with "or something essentially equivalent". I guess you would agree that qualifying it this way is a good idea. Mr Blandy did not care to do that though: "[...] is the only way to exploit the abilities of modern machines." I don't like that because it sounds like he's trying to popularize one approach to concurrency without even acknowledging that it is just one approach.
  - kibwen 11y ago
    It's important to mention here that Rust's approach to multithreading changes the rules of the game. Multithreading has rightfully earned its popular ire over the past few decades, but once you have a typesystem that prevents data races it's almost like there's an entirely new paradigm at your fingertips. So if Rust folk seem insistent on mentioning the use of threads, it's not because they want to push some agenda, it's because they want to overcome the suddenly-obsolete stigma against multithreading. Note as well that Rust intends to have world-class support for a wide variety of approaches to concurrency and parallelism. Threading and channels are already in the stdlib, and fork/join and SIMD are in the works now. The goal is to enable the programmer to be able to choose the best tool for the job.
  - deleted 11y ago
    [deleted]
vvanders 11y ago
I'll give it a shot. If you're talking about systems programming threads are by and large the main mechanism for concurrency. Only in really odd architectures do you see things like manually DMA'ing to separate execution units(ala PS3) and are certainly the exception to the rule.
- cgh 11y ago
  I agree that threads are probably the dominant form of concurrency in modern programming, but it's a relatively recent phenomenon. In pre-2.4 Linux kernels, for example, the threading was inadequate (remember LinuxThreads?) and the dominant model was multiprocessing, as it was in most of Unix itself. There are plenty of servers that still fork by default (Apache). I believe it was Windows that really popularised multithreading as a form of concurrent programming as process creation is so expensive on that platform. I recall Linus ranting against adding threading to the kernel on more than one occasion.
  - Animats 11y ago
    Threads were introduced in UNIVAC 1108 EXEC 8, first demoed in 1967 and running in production from about 1969. They were called "activities", but were created with "fork". The OS, which ran on multiprocessors, used them internally, and applications could use them as well. EXEC 8 also had synchronous and asynchronous I/O (callbacks). It's called OS 2200 today, and still running. When I went from EXEC 8 to UNIX in 1978, my main observation was that the I/O was better but the CPU management in UNIX was much worse.
    - cgh 11y ago
      Thanks for that, I had no idea. Were those actual shared-state threads or processes? Just wondering about the use of "fork".
      - Animats 11y ago
        Shared-state threads in the same memory space. They could do I/O independently, lock and unlock critical sections, and block on semaphores. Worked fine. To create a new thread, you called FORK$. See section 8, page 2, of the 1966 EXEC 8 manual.[1] Here are Djykstra's P and V functions for the UNIVAC 1108, to run in user space. Written in 1972.[2] I once added support for threads to Pascal for that machine. Had to add per-thread stacks and manage non-contiguous stack growth. [1] https://ia601603.us.archive.org/27/items/bitsavers_univac1100tiveReferenceManual1966_36328697/UP-4144_1108_Executive_Reference_Manual_1966.pdf https://ia601603.us.archive.org/27/items/bitsavers_univac110... [2] http://www.fourmilab.ch/documents/univac/fang/ http://www.fourmilab.ch/documents/univac/fang/
JoshTriplett 11y ago
More importantly, Rust goes out of its way to make it easy and safe to write multithreaded code...
- acconsta 11y ago
  Does Rust do anything to prevent deadlocks?
  - JoshTriplett 11y ago
    If you directly use low-level locking primitives, no. However, Rust provides many higher-level concurrency mechanisms that avoid the problem entirely. And typically, if you had some complex data structure with multiple levels of locks and ordering requirements on those locks to prevent deadlock, you'd want to encapsulate that data structure with methods that handle those locking requirements internally.
    - acconsta 11y ago
      >Rust provides many higher-level concurrency mechanisms I'm looking at the standard library and I see only threads and channels. Is there anything higher level? Parallel map, reduce, etc., something like OpenMP?
  - rancur 11y ago
    one of the design goals of rust is to design the language in such a way that they're simply not possible. I thought it was a new FOTM language but after reading a bit more about it I'm very excited for its future. That said, I wish they would have looked a little further outside Reddit's homepage rendering for parallelization inspiration. Reddit does not take a long time to render. However, CNN.com [which they looked at too] does, so...
    - kibwen 11y ago
      Be careful with terminology here when you say that something is simply not possible. The parent is asking about deadlocks, which includes scenarios such as entering an infinite loop or having a channel block on a message that will never come, and neither of these are things that Rust can guarantee will never happen. As I say in my sibling comment, what Rust's typesystem guarantees is the absence of data races, which is still an amazing achievement (unprecedented AFAIK) but is only a subset of the general category of race conditions.
geofft 11y ago
What are the other ways you want to model concurrency? Message-passing without shared memory does not exploit the abilities of modern machines. Message-passing with shared memory counts as multithreaded for the purposes of this discussion (language-level tracking of who else can access memory), regardless of whether it's a thread or a process or a task or a coroutine or a whatever.
- 0xdeadbeefbabe 11y ago
  Really anything beyond the standard posix one process many threads model. One process and no threads is how erlang does it as far as I can tell. Edit: No that's not exactly true http://stackoverflow.com/questions/7005759/erlang-on-multicore-cpu http://stackoverflow.com/questions/7005759/erlang-on-multico... But they do spawn a processes for each core.
  - geofft 11y ago
    How do you run code on multiple cores? (What's your kernel in this case, if it's non-POSIX?)
    - 15155 11y ago
      Send some kind of very-low-level interrupt, pointing each core at code to run, I am guessing? I could see Rust's ownership and multithreading amenability being extremely useful at this level, but admittedly I don't know enough.
      - dbaupp 11y ago
        Isn't that exactly what a thread is? Well, threads generally have some management by the OS to allow more threads than CPU/share tasks evenly, but at their core, they allow you to give each core some code to run on. (And yes, Rust's threading safety applies equally well to that. It doesn't care about the details of how code is running concurrently/in parallel, just that it could be.)
  - jamii 11y ago

AnimalMuppet 11y ago

I'm not the downvoter. But you may be getting the downvotes because you're throwing out snark ("Really? I'm not so sure I trust the author to give rust fair treatment anymore") and dogmatic statements ("An operating system that does multithreading is not the same as a modern machine") with no explanation or justification. It sounds like you're expecting us to agree with your statement as self-evident, or be relegated to the ranks of it ignorant if we don't. That is, it sounds like a one-up game ("I'm smarter/better informed than you"), rather than real conversation. If you don't want to come across that way, give us some explanation of what you're thinking and why. Give us some evidence that your statement is true. Something besides just dogmatic assertions that you're right and the author of the article is stupid and/or biased. Moving on... In the context of the OS, multithreading (or something essentially equivalent) is the only way to exploit the abilities of "modern" machines. But "modern" doesn't mean very modern (at least, as I understand it). It means the difference between MSDOS and Windows: "Windows is multitasking, whereas DOS... DOS is serially multitasking." (I don't recall who said that, but it was brilliant.) Without this capability, you're only running one program at a time. Now, I don't care if you implement this as "theads" or something else, but if you don't have it, your OS is pretty much worthless, and has been since about 1990.

0xdeadbeefbabe 11y ago
Thanks for the advice on dogmatism coupled with the statement about having a worthless OS since 1990. > In the context of the OS, multithreading (or something essentially equivalent) is the only way to exploit the abilities of "modern" machines. I noticed that you qualified multithreading with "or something essentially equivalent". I guess you would agree that qualifying it this way is a good idea. Mr Blandy did not care to do that though: "[...] is the only way to exploit the abilities of modern machines." I don't like that because it sounds like he's trying to popularize one approach to concurrency without even acknowledging that it is just one approach.
- kibwen 11y ago
  It's important to mention here that Rust's approach to multithreading changes the rules of the game. Multithreading has rightfully earned its popular ire over the past few decades, but once you have a typesystem that prevents data races it's almost like there's an entirely new paradigm at your fingertips. So if Rust folk seem insistent on mentioning the use of threads, it's not because they want to push some agenda, it's because they want to overcome the suddenly-obsolete stigma against multithreading. Note as well that Rust intends to have world-class support for a wide variety of approaches to concurrency and parallelism. Threading and channels are already in the stdlib, and fork/join and SIMD are in the works now. The goal is to enable the programmer to be able to choose the best tool for the job.
- deleted 11y ago
  [deleted]

vvanders 11y ago

I'll give it a shot. If you're talking about systems programming threads are by and large the main mechanism for concurrency. Only in really odd architectures do you see things like manually DMA'ing to separate execution units(ala PS3) and are certainly the exception to the rule.

cgh 11y ago
I agree that threads are probably the dominant form of concurrency in modern programming, but it's a relatively recent phenomenon. In pre-2.4 Linux kernels, for example, the threading was inadequate (remember LinuxThreads?) and the dominant model was multiprocessing, as it was in most of Unix itself. There are plenty of servers that still fork by default (Apache). I believe it was Windows that really popularised multithreading as a form of concurrent programming as process creation is so expensive on that platform. I recall Linus ranting against adding threading to the kernel on more than one occasion.
- Animats 11y ago
  Threads were introduced in UNIVAC 1108 EXEC 8, first demoed in 1967 and running in production from about 1969. They were called "activities", but were created with "fork". The OS, which ran on multiprocessors, used them internally, and applications could use them as well. EXEC 8 also had synchronous and asynchronous I/O (callbacks). It's called OS 2200 today, and still running. When I went from EXEC 8 to UNIX in 1978, my main observation was that the I/O was better but the CPU management in UNIX was much worse.
  - cgh 11y ago
    Thanks for that, I had no idea. Were those actual shared-state threads or processes? Just wondering about the use of "fork".
    - Animats 11y ago
      Shared-state threads in the same memory space. They could do I/O independently, lock and unlock critical sections, and block on semaphores. Worked fine. To create a new thread, you called FORK$. See section 8, page 2, of the 1966 EXEC 8 manual.[1] Here are Djykstra's P and V functions for the UNIVAC 1108, to run in user space. Written in 1972.[2] I once added support for threads to Pascal for that machine. Had to add per-thread stacks and manage non-contiguous stack growth. [1] https://ia601603.us.archive.org/27/items/bitsavers_univac1100tiveReferenceManual1966_36328697/UP-4144_1108_Executive_Reference_Manual_1966.pdf https://ia601603.us.archive.org/27/items/bitsavers_univac110... [2] http://www.fourmilab.ch/documents/univac/fang/ http://www.fourmilab.ch/documents/univac/fang/

JoshTriplett 11y ago

More importantly, Rust goes out of its way to make it easy and safe to write multithreaded code...

acconsta 11y ago
Does Rust do anything to prevent deadlocks?
- JoshTriplett 11y ago
  If you directly use low-level locking primitives, no. However, Rust provides many higher-level concurrency mechanisms that avoid the problem entirely. And typically, if you had some complex data structure with multiple levels of locks and ordering requirements on those locks to prevent deadlock, you'd want to encapsulate that data structure with methods that handle those locking requirements internally.
  - acconsta 11y ago
    >Rust provides many higher-level concurrency mechanisms I'm looking at the standard library and I see only threads and channels. Is there anything higher level? Parallel map, reduce, etc., something like OpenMP?
- rancur 11y ago
  one of the design goals of rust is to design the language in such a way that they're simply not possible. I thought it was a new FOTM language but after reading a bit more about it I'm very excited for its future. That said, I wish they would have looked a little further outside Reddit's homepage rendering for parallelization inspiration. Reddit does not take a long time to render. However, CNN.com [which they looked at too] does, so...
  - kibwen 11y ago
    Be careful with terminology here when you say that something is simply not possible. The parent is asking about deadlocks, which includes scenarios such as entering an infinite loop or having a channel block on a message that will never come, and neither of these are things that Rust can guarantee will never happen. As I say in my sibling comment, what Rust's typesystem guarantees is the absence of data races, which is still an amazing achievement (unprecedented AFAIK) but is only a subset of the general category of race conditions.

geofft 11y ago

What are the other ways you want to model concurrency? Message-passing without shared memory does not exploit the abilities of modern machines. Message-passing with shared memory counts as multithreaded for the purposes of this discussion (language-level tracking of who else can access memory), regardless of whether it's a thread or a process or a task or a coroutine or a whatever.

0xdeadbeefbabe 11y ago
Really anything beyond the standard posix one process many threads model. One process and no threads is how erlang does it as far as I can tell. Edit: No that's not exactly true http://stackoverflow.com/questions/7005759/erlang-on-multicore-cpu http://stackoverflow.com/questions/7005759/erlang-on-multico... But they do spawn a processes for each core.
- geofft 11y ago
  How do you run code on multiple cores? (What's your kernel in this case, if it's non-POSIX?)
  - 15155 11y ago
    Send some kind of very-low-level interrupt, pointing each core at code to run, I am guessing? I could see Rust's ownership and multithreading amenability being extremely useful at this level, but admittedly I don't know enough.
    - dbaupp 11y ago
      Isn't that exactly what a thread is? Well, threads generally have some management by the OS to allow more threads than CPU/share tasks evenly, but at their core, they allow you to give each core some code to run on. (And yes, Rust's threading safety applies equally well to that. It doesn't care about the details of how code is running concurrently/in parallel, just that it could be.)
- jamii 11y ago