What is the difference between multithreading, multiprocessing and asynchrony?

Question

Programming

Good afternoon.
I know there are a lot of articles on google on this topic.
But still, I would like to know the main difference between these things, when and what to use, differences in speed, etc.

Answer 1

Multiprocessing and multithreading refer to strategies for managing shared resources and optimizing idle times between tasks, while Asynchronous invocation refers to design patterns.
The multi-process approach to the solution allows you to throw off the processing of access to shared resources on the OS, and the multi-threaded approach allows the developer himself to more flexibly manage this division.
You always want to write single-threaded code that links into different executables that can be run as separate processes. But the problem lies at the system level - from the point of view of the speed of execution of work by the processor, the delays and waiting for packets to be transmitted over the network or to find and read a file are simply enormous. While the solution of one task is waiting for the database response, it is irrational to waste processor time on idle work of active waiting, when all the process does is ask the OS ten times per ms whether the answer has come, whether the answer has come, whether the answer has come ... It will take a long time until the OS realizes that the process is not doing anything useful, and while it switches the context, unloads one process, loads another, a response may come for the process that was waiting for it. But now you have to wait until the OS loads it.
Another problem with the process approach is resource capture. Using multithreading, you can save on the fact that a process will access system resources, and threads can simply own the resource together, and how this ownership will be shared is decided by the developer himself. Moreover, the task of reading from shared memory is easier if it happens within the same process, and inter-process communications are always more heavy.
Asynchronous call is related to high-level languages. When a method is called synchronously, from the point of view of the calling code, the result of the method is expected. With an asynchronous call, instead of waiting, there is almost immediately a transition to the execution of the following instructions after calling the asynchronous method.
As part of an asynchronous call, futures and promises can also be declared, which in fact separate memory allocation, initialization, and assignment of the value returned by the asynchronous method.
How an asynchronous call will actually be implemented - whether it represents waiting for the execution of a transaction, or receiving a message from a broker, waiting for a result from another process or a task that is being solved in the same process, but in a different thread - this already depends on the developer. selected design solutions.

Answer 2

Processes are parallel threads (normal).
Threads (Pythonian) are coroutines.
Coroutines are a bunch of sequential threads.
Async is a queue of sequential threads.

Answer 3

I read the answers of colleagues, and decided to insert my 5 cents:
- multiprocessing. each task is a complete OS process. processes can be the same, or completely different. sockets are used for communication between processes (we will tactfully keep silent about udp). there are 2 types of sockets, network and unix (unix sockets, of course, are present on unix systems, under windows there may be a similar IPC mechanism, but I'm not in the subject, so I won't confuse you). The fundamental difference for sockets is that through Unix sockets, interaction is possible only within the same machine, for network sockets there is no such restriction.
- multithreading. The main difference from processes is that you cannot create an independent thread, the process that does this always starts first. From the point of view of the OS scheduler, the difference between threads and processes is very small - each process starts in its own address space, with its own stack and descriptors. all threads share address space with the parent and other threads. of the pluses - the interaction between threads is as fast as possible, its possibilities are limited only by the imagination of the author of the program. of the minuses - interaction between threads is possible only within the framework of one program, interaction with the outside world does not differ from the case of many processes, due to the fact that all data is available to all threads at once, you have to use special programming techniques involving locks.
- asynchronous asynchronous programming is nothing more than cooperative multitasking. there is always a dispatcher who knows how to switch asynchronous tasks. in some newfangled languages, like go, the compiler implicitly inserts dispatcher calls so that goroutines can execute in parallel. in languages ​​where asynchrony support appeared later than the language itself, we have to explicitly specify whether we call synchronous or asynchronous code. when calling asynchronous code, the scheduler is called, which adds the requested function to the queue and switches to another task. sometimes you have to explicitly refer to the dispatcher if, for example, our asynchronous task will be executed obviously for a long time.