What is technical the difference between a thread and an async-operation?

Question

I assume that two threads are working on a single cpu like this:

| Thread1 | Thread2 |
|———|———|
| a1 | b1 |
| a2 | b2 |
| a3 | b3 |

And are batched like this on the CPU

a1-b1-a2-b2-a3-b3

In: Technology

Answer 1

Exact semantics for what a thread is will differ between different operating systems, but at a very high level, you can think of threads as additional jobs within a single running program that a computer is expected to switch between.

On a modern, multiple-core processor, the computer can actually do multiple things at the same time. If you have a program, it might start a thread to handle input from the keyboard and another thread to handle drawing to a window – and *both* could be being ran by the computer at the same time.

Above you refer to a single cpu. You can typically still create multiple threads, even if the computer physically can only be doing one thing at any instant in time. What would happen is that the computer would periodically switch between threads (say every 1/100 of a second), giving the sort of illusion that both are running at the same time.

The use of multiple threads can make certain programs easier to write or even perform certain tasks faster, but can also cause problems as communication between threads is a complicated matter.

An asynchronous operation can be thought of as something that doesn’t block. When writing a program, it will often involve making calls to the operating system or utility libraries to do things – a good example is a library for manipulating files on disk.

Such a library will likely include a call to “write some data to a file”.

If the library offers a synchronous interface (this would be the most common), then your program will block until the call has completed. In the above example, when the call completes you would know that the data has finished being written to the disk.

With an asynchronous interface, it’s different, you might ask to write out some data and get back an “okay, I’ll try” response. You program would continue, with the writing operation occurring in the background. Here, you have no immediate way of knowing whether the operation is complete without introducing another mechanism such as an additional call to check the status of a previous request.

It’s quite possible that a library offering an asynchronous interface like this is actually implemented by creating threads to do the work (such as writing out to disk), allowing your program to carry on regardless.