Async/Sync & Yield in Tokio

In the world of Rust and asynchronous programming, the Tokio crate stands as a powerful tool. Tokio enables developers to build highly concurrent and efficient applications, whether they involve I/O operations, network communication, or other asynchronous tasks. One of the distinguishing features of Tokio is its ability to seamlessly combine both synchronous (blocking) and asynchronous code.

The Tokio crate in Rust provides a versatile platform for building both synchronous and asynchronous applications. Whether you need to integrate blocking code into an asynchronous application or build a highly concurrent system, Tokio's features, including tokio::task::spawn_blocking and tokio::spawn, allow you to achieve your goals while maintaining the safety and performance characteristics that Rust is known for. By effectively leveraging both approaches, you can build robust and efficient applications that meet your specific requirements.

So there are 2 types of tasks can be created using tokio

1. Detached task (Async/Non-blocking) : tokio::spawn()
2. Non-Detached (Sync/Blocking) :tokio::task::spawn_blocking()

Let's study each of them in detail:

Detached Tasks:

When you use tokio::spawn, you are creating a detached task. A detached task is one that is started asynchronously and runs independently of the current task, often referred to as the "parent" task. The detached task goes into the task queue managed by the Tokio runtime, and it executes concurrently with the other tasks in the queue.

Here's what happens when you spawn a detached task:

1. Launching an Async Task: When you call tokio::spawn, you're essentially launching an asynchronous task. This task is represented as a future, which is a unit of work that may complete at some point in the future.
2. Task Remains Active: The spawned task remains active independently of the task that spawned it. It continues to execute in the background, and the parent task doesn't wait for it to complete.
3. Task Queue: The Tokio runtime manages a task queue where all the asynchronous tasks are scheduled for execution. The detached task joins this queue and competes for resources with other tasks in the queue.
4. Concurrency: If you are in a multi-threaded context, the Tokio runtime may choose to run the detached task on a different thread. This is an essential aspect of Tokio's runtime, as it enables true asynchronous and concurrent execution.
5. Independence: Detached tasks are independent of each other and the parent task. They can run concurrently, and their execution order is determined by the runtime and the availability of resources.
6. Asynchronous Behavior: The power of detached tasks is in enabling asynchronous behavior. For example, you can spawn multiple tasks to perform I/O operations or handle incoming requests concurrently without blocking the main thread.

Detached tasks are ideal for scenarios where you want to perform work concurrently without waiting for the results immediately. For example, when building a web server, you might spawn a detached task to handle each incoming HTTP request, allowing multiple requests to be processed at the same time.

Here's a simplified example of using to launch detached tasks: tokio::spawn

const cntr: i8 = 5; 
async fn chant_HareRam() {
    for i in 0..cntr {
        println!("HareRama {i}");
    }
}

async fn chant_HareKrishana() {
    for i in 0..cntr {
        println!("HareKrishana {i}");
    }
}

async fn chant_JaiBajrangbali() {
    for i in 0..cntr {
        println!("JaiBajrangBali {i}");
    }
}

#[tokio::main]
async fn main() {
    let task = tokio::task::spawn(async {
        for i in 0..cntr {
            println!("Om NamahShivaya {i}");
        }
    });
    let _ = tokio::join!(
        tokio::spawn(chant_HareRam()),
        tokio::spawn(chant_HareKrishana()),
        tokio::spawn(chant_JaiBajrangbali()),
        task,
    );
}
/*
Op =>

Om NamahShivaya 0
HareKrishana 0
HareKrishana 1
Om NamahShivaya 1
JaiBajrangBali 0
Om NamahShivaya 2
HareRama 0
HareKrishana 2
HareKrishana 3
HareKrishana 4
HareRama 1
HareRama 2
HareRama 3
Om NamahShivaya 3
Om NamahShivaya 4
JaiBajrangBali 1
JaiBajrangBali 2
JaiBajrangBali 3
JaiBajrangBali 4
HareRama 4
*/        

In the above example, and are detached tasks that run concurrently with the main task. They are added to the Tokio task queue, and the Tokio runtime manages their execution.

Example 2:

In below example I am not using the join and also I am making the main task also executing concurrently the detached tasks.

const cntr: i8 = 5; 
async fn chant_HareRam() {
    for i in 0..cntr {
        println!("HareRama {i}");
        tokio::time::sleep(std::time::Duration::from_secs(1)).await;
    }
}

async fn chant_HareKrishana() {
    for i in 0..cntr {
        println!("HareKrishana {i}");
        tokio::time::sleep(std::time::Duration::from_secs(1)).await;
    }
}

async fn chant_JaiBajrangbali() {
    for i in 0..cntr {
        println!("JaiBajrangBali {i}");
        tokio::time::sleep(std::time::Duration::from_secs(1)).await;
    }
}

#[tokio::main]
async fn main() {
    let task = tokio::task::spawn(async {
        for i in 0..cntr {
            println!("Om NamahShivaya {i}");
            tokio::time::sleep(std::time::Duration::from_secs(1)).await;
        }
    });

    // Spawn two detached tasks
    tokio::spawn(chant_HareRam());
    tokio::spawn(chant_HareKrishana());
    tokio::spawn(chant_JaiBajrangbali());
    task;


    // Main task continues executing concurrently with t1 and t2
    for k in 0..5 {
        println!("Shree Ganeshaya Namah {}", k);
        tokio::time::sleep(std::time::Duration::from_secs(1)).await;
    }
}
/*

Running `/home/amit/OmPracticeRust/AsyncExperements/Ardan-1HourAsync/target/debug/tokio_spawn`
Shree Ganeshaya Namah 0
JaiBajrangBali 0
HareKrishana 0
HareRama 0
Om NamahShivaya 0
Shree Ganeshaya Namah 1
HareKrishana 1
Om NamahShivaya 1
JaiBajrangBali 1
HareRama 1
Shree Ganeshaya Namah 2
Om NamahShivaya 2
HareRama 2
HareKrishana 2
JaiBajrangBali 2
Shree Ganeshaya Namah 3
JaiBajrangBali 3
HareRama 3
HareKrishana 3
Om NamahShivaya 3
Shree Ganeshaya Namah 4
HareRama 4
Om NamahShivaya 4
JaiBajrangBali 4
HareKrishana 4

*/
        

Detached tasks are a fundamental building block for writing highly concurrent and efficient asynchronous Rust applications with Tokio. They enable you to make the most of Rust's asynchronous capabilities while keeping your code responsive and scalable.

Non-Detached Tasks :

In Tokio, tasks created using tokio::task::spawn_blocking() are always detached by default. However, if we want to create non-detached tasks, we can use the function, which is designed for running synchronous or blocking code in a separate thread. Here's a complete example of using to launch non-detached

tokio::task::spawn_blocking is a function in Tokio specifically designed for running synchronous or blocking code in a separate thread. It is used when you have code that might block, like CPU-bound computations or code that relies on synchronous I/O operations (e.g., blocking file I/O, database queries, or interactions with synchronous libraries).

Key Characteristics:

1. Non-Detached: Tasks created with are non-detached. This means they are bound to the current thread and run synchronously in that thread. The Tokio event loop continues to run concurrently with non-detached tasks, ensuring that other asynchronous tasks can still progress.tokio::task::spawn_blocking
2. Thread-Based Concurrency: internally creates a new OS thread to run the blocking code. This allows you to take advantage of multi-core processors, but it comes with the overhead of thread creation and management.spawn_blocking
3. Blocking Code: The code provided to is expected to be blocking or synchronous. It can perform operations that would normally block the main thread, but it won't block the Tokio event loop because it runs in a separate thread.spawn_blocking
4. Resource Intensive: Due to the use of OS threads, spawning many non-detached tasks with can be resource-intensive. Use it judiciously for code that genuinely requires blocking operations.spawn_blocking

Suitable Scenarios:

Use tokio::task::spawn_blocking in the following scenarios:

1. Synchronous I/O Operations: When interacting with synchronous I/O libraries (e.g., synchronous file I/O or database drivers) that would block the main thread.
2. CPU-Bound Work: For CPU-bound computations, like intensive mathematical calculations or data processing, that could otherwise block the Tokio event loop.
3. Interoperability: When integrating with synchronous third-party libraries or frameworks that are not designed for asynchronous programming.
4. Legacy Code: When dealing with legacy codebases that are synchronous and can't be easily refactored into asynchronous code.

use tokio::time::Duration;
use tokio::task;

async fn async_task() {
    for i in 0..5 {
        println!("Async Task: Jai Shree Ram - Count {}", i);
        tokio::time::sleep(Duration::from_secs(1)).await;
    }
}

fn blocking_task() {
    for j in 0..5 {
        println!("Blocking Task:Jai Bajrang Bali - Count {}", j);
        std::thread::sleep(Duration::from_secs(1))
    }
}

#[tokio::main]
async fn main() {
    // Spawn an asynchronous task (detached)
    let async_handle = tokio::spawn(async_task());

    // Spawn a non-detached task using spawn_blocking
    let blocking_handle = tokio::task::spawn_blocking(|| {
        blocking_task();
    });

    // Main task continues executing concurrently with async_handle and blocking_handle
    for k in 0..5 {
        println!("Main Task: Count {}", k);
        tokio::time::sleep(Duration::from_secs(1)).await;
    }

    // Wait for the async_task to complete (optional)
    async_handle.await.expect("Async Task panicked");

    // The blocking_task automatically runs to completion

    println!("All tasks have completed.");
}
/*

Running `target/debug/task_blocking_demo`
Async Task: Jai Shree Ram - Count 0
Main Task: Count 0
Blocking Task:Jai Bajrang Bali - Count 0
Blocking Task:Jai Bajrang Bali - Count 1
Async Task: Jai Shree Ram - Count 1
Main Task: Count 1
Blocking Task:Jai Bajrang Bali - Count 2
Async Task: Jai Shree Ram - Count 2
Main Task: Count 2
Blocking Task:Jai Bajrang Bali - Count 3
Async Task: Jai Shree Ram - Count 3
Main Task: Count 3
Blocking Task:Jai Bajrang Bali - Count 4
Async Task: Jai Shree Ram - Count 4
Main Task: Count 4
All tasks have completed.

*/        

1. We have two functions, async_task and blocking_task. async_task is an asynchronous function that prints messages with a one-second delay between counts, and blocking_task is a blocking function that does the same.
2. In the main function, we spawn an asynchronous task using tokio::spawn(async_task()). This task is detached and runs concurrently with the main task.
3. To create a non-detached task, we use tokio::task::spawn_blocking . We wrap the blocking_task function within it. This allows the blocking code to run in a separate thread without affecting the Tokio event loop. The blocking_task function is non-detached, which means it's bound to the current thread and runs synchronously.
4. The main task continues executing concurrently with both async_handle and blocking_handle . It prints its own count messages. async_handle blocking_handle
5. You have the option to wait for the async_task to complete using await if needed, but the blocking_task will automatically run to completion.
6. Finally, we print a message to indicate that all tasks have completed.

After going through all of the above about synchronous apis of tokio(tokio::spawn) , we still have below questions :

Question1 : Why should I use tokio::spawn() for spawning the synchronously when the main thread (main function) is by default synchronous ?

Question2 : Why should I use std::thread::spawn() for spawning the synchronously when I can create the seperate thread using std::thread::spawn() is also by default synchronous?

Answer both of the above question is almost same , but still adress both one by one.

Question1: Why should I use tokio::spawn () for spawning the synchronously when the main thread (main function) is by default synchronous?

The key difference between using tokio::task::spawn_blocking and writing synchronous code without Tokio is the context in which our code runs and the way it interacts with Tokio's asynchronous runtime.

1. tokio::task::spawn_blocking with Tokio:When we use tokio::task::spawn_blocking, we are running synchronous or blocking code within the Tokio runtime. This means our blocking code runs within the context of the Tokio event loop, and it doesn't block the entire event loop, allowing other asynchronous tasks to continue executing concurrently.This is valuable when we need to integrate blocking code within an asynchronous application, and we want to avoid blocking the event loop, which can lead to poor performance or unresponsiveness in our application.spawn_blocking spawns the blocking code in a separate OS thread, which allows it to run concurrently with other Tokio tasks and utilize multi-core processors.Use spawn_blocking when we have synchronous or blocking code that needs to be integrated into an existing Tokio-based application or when you want to maintain the benefits of concurrency and responsiveness that Tokio provides.
2. Writing Synchronous Code without Tokio:When we write synchronous code without Tokio, it typically runs in the main thread and can block the entire application's execution. If we have CPU-bound or long-running synchronous operations in our code, it can cause our application to become unresponsive during these operations.In this scenario, there's no event loop or concurrency management provided by Tokio. Synchronous code runs on a single thread and is not well-suited for managing concurrency, especially in scenarios with many I/O-bound tasks.We might choose to write synchronous code without Tokio if we have a straightforward, single-threaded application that doesn't require the features and benefits of asynchronous programming, or if we have code that is inherently synchronous and doesn't need to be integrated into an asynchronous context.Finally , the difference lies in how our code operates within the context of an asynchronous runtime (Tokio) or outside it. If our application is primarily asynchronous and we need to integrate synchronous code, tokio::task::spawn_blocking is the way to go. If we writing a small, single-threaded, synchronous application without asynchronous features, we can write synchronous code without Tokio in the main thread itslef. The choice depends on the specific requirements of project and the need for concurrency and responsiveness.

Question2 : Why should I use tokio::task::spawn_blocking() for spawning the synchronously when I can create the seperate thread using std::thread::spawn() is also by default synchronous?

Using tokio::task::spawn_blocking and spawning a separate thread with std::thread::spawn() are two different approaches to executing synchronous code concurrently. Let's explore the differences between the two:

1. tokio::task::spawn_blocking with Tokio:tokio::task::spawn_blocking is part of the Tokio library and is designed to execute synchronous or blocking code within the Tokio runtime. This allows you to integrate blocking code into an existing Tokio-based asynchronous application as we mentioned when answering the 1st question.While spawn_blocking creates a separate thread to execute the blocking code, it still operates within the context of the Tokio event loop. This means that other asynchronous tasks managed by Tokio can continue to run concurrently without being blocked by the synchronous task.Using tokio::task::spawn_blocking can help you maintain the benefits of Tokio's asynchronous runtime, such as efficient resource utilization and concurrency management.
2. std::thread::spawn() without Tokio:std::thread::spawn() is part of the Rust standard library and is used to create completely separate OS threads to run code concurrently.When we use std::thread::spawn(), you are not within the context of an asynchronous runtime like Tokio. Each spawned thread operates independently, and there is no event loop managing them.While this approach allows for true parallelism on multi-core processors, it doesn't provide the benefits of an asynchronous runtime like Tokio, such as managing asynchronous tasks, I/O multiplexing, and cooperative multitasking.

Let me list the key differences:

• tokio::task::spawn_blocking is designed for running synchronous code within the Tokio runtime, allowing for concurrency within the context of an asynchronous application.
• std::thread::spawn() creates completely separate OS threads and is not tied to any specific asynchronous runtime. It provides true parallelism but lacks the features and benefits of asynchronous runtimes.

Which approach to use depends on the specific requirements of the project:

• If we are working on an asynchronous application using Tokio and need to execute synchronous code without blocking the event loop, tokio::task::spawn_blocking is the appropriate choice.
• If we have a use case that requires true parallelism or you are not using an asynchronous runtime like Tokio, std::thread::spawn() can be a suitable option for executing code in separate threads.

Ultimately, the choice between these approaches depends on the project's requirements, concurrency needs, and whether we are working within the context of an asynchronous runtime.

Yield:

The use of yielding, task scheduling, and the decision to use blocking or non-blocking operations depend on the specific requirements of your application. Yielding is a key mechanism in asynchronous programming that ensures responsiveness and efficient resource utilization, while blocking is used when there's a need for CPU-bound tasks that can't be efficiently handled asynchronously. The choice depends on the nature of the task and the performance requirements of the application.

tokio::task::yield_now().await;        

1. Yielding Control: In asynchronous programming, tasks are designed to execute in a non-blocking manner. When an asynchronous function encounters an operation that may block, such as waiting for I/O, it can yield control back to the event loop. This means that instead of blocking the entire program, the task voluntarily pauses and allows other tasks to run. Yielding is achieved using keywords like await in Rust's async/await syntax. When you await an asynchronous operation, your task yields control to the event loop, and it will resume from where it left off when the awaited operation is complete. This mechanism allows the event loop to efficiently manage multiple tasks, ensuring that one task's blocking operation doesn't prevent others from making progress.
2. Task Scheduling: In an asynchronous runtime like Tokio, tasks are scheduled to run by the event loop. The event loop ensures that tasks are executed in a fair and non-blocking manner.Tasks are placed in a queue, and the event loop schedules them based on their readiness. A task that has yielded control or is waiting for some asynchronous operation (e.g., network I/O) will be placed at the back of the queue.The event loop selects the next task to run, usually the one at the front of the queue, and executes it until it yields or performs an asynchronous operation. Then, it moves to the next task and so on, ensuring efficient use of resources.
3. Yielding vs. Blocking:Yielding is a way to avoid blocking the event loop. It's a way to make efficient use of system resources and provide responsiveness in an application.However, if an asynchronous task needs to perform a long-running, CPU-bound operation that is not amenable to asynchronous waiting (e.g., complex computations), repeatedly yielding control might not be sufficient. In such cases, you may need to consider a blocking operation.Blocking in an asynchronous context can be achieved using mechanisms like tokio::task::spawn_blocking (in Tokio). It allows you to execute synchronous code in a separate thread, preventing it from blocking the main event loop. This is useful when you need to run CPU-bound tasks efficiently without slowing down other asynchronous tasks.

GitHub examples:

NadigerAmit/RustExperements: Contains Rust code based on my experiance (github.com)

Thanks for reading till end , please comment if you have anything .