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.
}
Using Message Passing to Transfer Data Between Threads:
Here’s the idea in a slogan from the Go language documentation: “Do not communicate by sharing memory; instead, share memory by communicating.”
One major tool Rust has for accomplishing message-sending concurrency is the channel,
A channel in programming has two halves: a transmitter and a receiver.
A channel is said to be closed if either the transmitter or receiver half is dropped.
{
We create a new channel using the mpsc::channel function; mpsc stands for multiple producer, single consumer. In short, the way Rust’s standard library implements channels means a channel can have multiple sending ends that produce values but only one receiving end that consumes those values
}
Priority Performance:
Stealing_Join:
calling join() is similar to spawning two threads.
execute code in parallel when there are idle CPUs to handle it.
When join is called from outside the thread pool, the calling thread will block while the closures execute in the pool. When join is called within the pool, the calling thread still actively participates in the thread pool. It will begin by executing closure A (on the current thread). While it is doing that, it will advertise closure B as being available for other threads to execute. Once closure A has completed, the current thread will try to execute closure B; if however closure B has been stolen, then it will look for other work while waiting for the thief to fully execute closure B. (This is the typical work-stealing strategy).
Send is require because we have jump from quick func(thread a) to part func(thread b) frequently
Atomic:
Atomic types provide primitive shared-memory communication between threads, and are the building blocks of other concurrent types.
This module defines atomic versions of a select number of primitive types, including AtomicBool, AtomicIsize, AtomicUsize, AtomicI8, AtomicU16, etc. Atomic types present operations that, when used correctly, synchronize updates between threads.
Each method takes an Ordering which represents the strength of the memory barrier for that operation. These orderings are the same as the C++20 atomic orderings. For more information see the nomicon.
Atomic variables are safe to share between threads (they implement Sync) but they do not themselves provide the mechanism for sharing and follow the threading model of Rust. The most common way to share an atomic variable is to put it into an Arc (an atomically-reference-counted shared pointer).
Atomic types may be stored in static variables, initialized using the constant initializers like AtomicBool::new. Atomic statics are often used for lazy global initialization.
Spin_Loop_Yeild:
also known as busy loop and spin loop-If you want to sleep pause a thread for short amounts of time, or if your application is sensitive to timing, use a spin loop
Sleep:
A sleep is a request to the OS that the thread should be suspended until the time has passed