which parts of your code on different threads will run. This can lead to problems, such as:
Race conditions, where threads are accessing data or resources in an inconsistent order
Deadlocks, where two threads are waiting for each other to finish using a resource the other thread has, preventing both threads from continuing
Bugs that happen only in certain situations and are hard to reproduce and fix reliably
{Programming languages implement threads in a few different ways:
APIs to create threads is sometimes called 1:1, meaning one operating system thread per one language thread.
the green-threaded model is called the M:N model: there are M green threads per N operating system threads, where M and N are not necessarily the same number.
The green-threading M:N model requires a larger language runtime to manage threads.
As such, the Rust standard library only provides an implementation of 1:1 threading.
Because Rust is such a low-level language, there are crates that implement M:N threading if you would rather trade overhead for aspects such as more control over which threads run when and lower costs of context switching, for example.
}
{
Blocking a thread means that thread is prevented from performing work or exiting.
}
{
you can divide a calculation into independent parts, split those parts across threads, and then use a Mutex<T> to have each thread update the final result with its part.
}