Thread Pool
Implementing and Understanding Thread Pool in Rust
After watching this video by
on Thread Pool, curious I wanted to see if I could reimplement the Go code in Rust (if you are new here I am still Rusty at Rust programming and this newsletter is a way of articulating my thoughts). However, I do believe to fully understand the implementation it is important to have some pre-requisite knowledge about multithreading, channels and smart pointers in Rust.If you are interested in learning the prerequisites, check out my previous publications.
Understanding Multithreading and Channels in Rust
Please don’t forget to give me your feedback.
What is a Threadpool?
Like the name suggests a Threadpool is a pool (accumulation) of threads from which the user can pick one, to run a particular job or computation. Why do we need a thread pool? Well, in a multithreaded application, we can spin up an unlimited number of threads depending on the resources available. However, having a large number of threads can exhaust the memory, burden the CPU and increase context switching and interrupts. This can be not nice. So we want to limit the resources that are used by our program.
Designing Our Threadpool
The thread pool data structure contains two elements—the Workers (worker queue) which stores the thread handler of the spawned thread. The second element is the sender side of the mpsc (multi-producer single consumer) channels.
We start by initializing the Threadpool with a specific number of workers in the queue. The new() method is responsible for getting a channel for communication between the main thread and the child threads. The new threads are spawned with the cloned reference to the receiver side of the channel. There can only be one receiver on the single consumer channel, so the receiver must contest for the lock. When available the data sent by the sender can be received.
The send_job() method on the thread pool can send data on the channel (in our case we send a function to execute on the thread). The client threads run the function locally and start to wait on the receiver for more data (the receiver is blocking if there is no data on the channel).
When the User is done, the complete_and_return() function is called which signals the child thread to stop receiving on the channel. Then they are joined back to the main thread.
The ThreadPools provide a solution to restrict the application to use only a certain number of threads from the thread pool. This will benefit the application and put less strain on the server by consuming a constant amount of resources.
Check out the entire source code on my Github: Threadpool
Connect with me on Linkedin: anvayabn