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

907 views

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

4 Answers

Anonymous 0 Comments

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.

Anonymous 0 Comments

A thread is when you ask the operating system to start running another part of the program at the same time. If there are more parts running than CPU cores, the operating system will switch between them. Threads have a bunch of features (like separate stacks) that make them relatively “expensive”. A program shouldn’t have thousands of threads because it will waste memory and time.

“Async tasks” depend on the programming language, but they’re generally things you can do in the background that are too short to be their own thread. The program will create one thread (or a few) and then that thread (or those threads) will do async tasks whenever they are ready to be done. This means a new thread doesn’t need to be created for every task.

“Async tasks” can also be things that don’t use a thread at all, as long as the program can remember it’s waiting for something to happen. For example, waiting for the user to type something could be an async task. The program won’t use a thread to wait for the user to type something (because that’s a waste of a thread) but it knows that when the user does type something, the task should be marked as completed.

“Async tasks” got a big boost in popularity some time ago because: people wanted to do more things asynchronously (in the background), people realised that having a thread for every single thing is not efficient, and because JavaScript basically forces you to use them so people got used to them.

Anonymous 0 Comments

A thread is a *long-lived* independent running part which is *initiated by the main program*, for example receiving traffic from a network device and once it has received enough, inform the main program that the data is there.

An asynchronous operation is a *short-lived* independent running *stub part* which can be initiated by anything, for example the writing of analysed data to disk.

Now it is fair to say that asynchronous operations are threads also and could be implemented as threads by the coder too and that is 100% true. It is just that their purpose is different (Long lived versus long lived) and where they are started (main program versus at the end of some process).

Anonymous 0 Comments

Here is an analogy that might help.

Lets say you’re busy but you need to drop your car to the garage for a service then pick it up later.

You could delegate this to someone else: they bring your car to the garage, sit around until its fixed and drop it back. The upside is you can work away as normal. The downside is you need to find someone else, and they’re wasting their time waiting for your car to be fixed.

Or you could try to find 10 spare minutes in the morning to drop it down, and 10 minutes in the afternoon to collect it. The downside is its 20 minutes out of your day, and more work coordinating your time. The upside is you can do it all yourself and nobody is waiting around.

The first is kind of like a thread, the second is kind of like an async task.