mirror of
https://github.com/darkicewolf50/RustBrock.git
synced 2025-06-15 13:04:18 -06:00
50 lines
3.1 KiB
Markdown
50 lines
3.1 KiB
Markdown
# Fearless Concurrency
|
|
Another one of Rust's major goals is handling concurrent programming safely and efficiently.
|
|
|
|
*Concurrent programming* is where different parts of a program execute independently.
|
|
|
|
*Parallel programming* is where different parts of a program execute at the same time.
|
|
|
|
These are becoming increasingly important as more computers take adantage of thier multiple processors.
|
|
|
|
Historically programming in these contexts has been difficult and error prone, which Rust hops to change this fact.
|
|
|
|
Intially this was though of as two seperate challenges by the Rust team.
|
|
|
|
Over time though the team discovered that ownership and type systems are a powerful set of tools to help manage memory safety *and* concurrency problems.
|
|
|
|
By usng these systems, many concurrency erros are compile-tme erros in Rust rather than runime erros.
|
|
|
|
This therefore, instead of making you spend lots of time trying to repoduce the exact circumstances under wihch a runtime concurrency buh occurs.
|
|
|
|
The inccorect code will be refused at compile time and present an error that explains the problem.
|
|
|
|
This results that you can fix your code while you are working on it rather than potentailly after it has been integrated into production.
|
|
|
|
This has been nicknamed this aspect of Rust *fearless concurrency*.
|
|
|
|
Fearless concurrency allows you to write code that is free of subtle bugs and is easy to refactor without introducing new bugs.
|
|
|
|
Note that we will simplify and refer to many of the problems as *concurrent* rather than being more precise by saying *concurrent and/or parallel*.
|
|
|
|
If this book were about concurrency and/or parallelism then the book would be more specific.
|
|
|
|
For this chapter a mental substitution of *concurrent and/or parallel* should be made whenever the use of *concurrent* is made.
|
|
|
|
|
|
Many lnaguages are dogmatic about the solutions they offer for handling concurrent problems.
|
|
|
|
An example of this is is in Erlang. This has elegant functionality for message-passing concurrency but has only obscure ways to share state between threads.
|
|
|
|
This supporting only a subset of possible solutions is a reasonable stategy for giher-level languages, because a higher-level language promises benefits from giving up some control to gain abstractions.
|
|
|
|
However, lower-level languages are expected to provide the solution with the best performance in any given situation and have fewer abstractions over the hardware.
|
|
|
|
This means that Rust offers a variety of tools for modeling problems in whatever way is appropriate for the situation and requirements.
|
|
|
|
Here are the topics that will be covered in this section:
|
|
- How to create threads to run multiple pieces of code at the same time [Section Link Here](./Simultaneous%20Code%20Running.md)
|
|
- *Message-passing* concurrency, where channels send messages between threads [Section Link Here](./Passing%20Data%20Between%20Threads.md)
|
|
- *Shared-state* concurrency, where multiple threads have access to some piece of data [Section Link Here](./Shared%20State%20Concurrency.md)
|
|
- The `Sync` and `Send` traits, which extend Rust's concurrency guarantees to use-defined types as well as types provided by the std library [Section Link Here](./Sync%20and%20Send.md)
|