Lightweight threads and Erlang

Threads are usually used to execute parallel computing and increase concurrency for a large number of blocking operations. When the number of threads is greater than the number of CPUs, there will be additional scheduling overhead for the threads, so too many threads will lead to a reduction in computing performance. When a computer executes a computing task, it usually needs to interact with various Io devices. These devices are several orders of magnitude slower than the CPU and memory, and some tasks need to use these devices serially, in this case, the resources of these devices can be effectively utilized by using multiple threads.

In addition to creating a large number of threads, you can also use Asynchronous Io to complete the same function. The asynchronous Io principle is very simple. A user thread initiates a request at a time (for Io, there are usually only two types of read and write). When the IO Device is ready, it calls back the process specified by the user, asynchronous IO does not block user threads. You can use a few threads to perform the same functions. Asynchronous Io is not easy to use. Currently, many network applications are used.

Asynchronous Io complicate programming. It requires the program to follow the request/callback method. A complete process may be divided into multiple fragments, making the program architecture very difficult to control, in this case, lightweight threads can be introduced.

A lightweight thread is actually a pseudo thread, which is controlled by the user for "Thread" switching. When an operation needs to wait for asynchronous completion, it tells the scheduler to pause its execution and switch to another task. When an IO event occurs, it is resumed from the breakpoint. In Windows, fiber is provided, and there is no corresponding implementation in Linux (note ). Stateless Python also implements lightweight threads, which are used by the eve server of the famous online game. The continuation mechanism of other languages can also implement similar functions.

Although there are so many lightweight threads, almost all of them have to be scheduled on their own, it is still quite difficult to use. There cannot be blocking operations in each "Thread"; otherwise, the entire mechanism will become invalid.

Of course there are some perfect solutions. Erlang can be regarded as relatively perfect. Erlang implements lightweight threads and schedulers on virtual machines and becomes the basis of language. In Erlang, users do not control threads, but create a large number of lightweight threads. Erlang is called a process (process. Each process can represent an active object, which has an event loop, and each process communicates through messages. After a process sends a message to another process, it can enter the receiving status. At this time, the real thread switches the execution right to another process. If the other process gets the execution right, if it replies to the message, after switching the execution right, the process that sent the original message gets the execution right, and it can receive the message. This complicated process may only need one thread to complete, the program is written in synchronous mode, and you don't feel the underlying switch at all. The only thing you need is to create a process without scruples (don't take it seriously, just close your hands when creating a few 100,000 processes ). At the underlying layer of Erlang, only one thread is required to complete these complex tasks, because no process is blocked. On multiple CPU machines, you can choose to create processes with the same number of CPUs to improve efficiency.

Erlang itself is perfect, but it cannot avoid using some "imperfect" libraries. For example, if it wants to call MySQL and block the query database, it cannot block the Erlang virtual machine completely? At this time, there are two options: one is to use the MySQL API instead of the Erlang to implement the MySQL Remote Call protocol, and the other is to write a MySQL call program, it communicates with Erlang through the network or other methods, receives query commands, executes queries, and concurrently returns data. This is called the C Node Method in Erlang.

In Erlang, how does one block all these complicated asynchronous calls? Is it just a simple synchronous operation? Because it uses an asynchronous mechanism at the underlying layer, it encapsulates the entire system with asynchronous operations, and opens it to users with lightweight threads, which are completely synchronous. users do not need to explicitly request thread switching, the Erlang virtual opportunity is scheduled in the unit of a function. Because Erlang does not use loop statements and uses recursion instead, even an infinite recursion will not result in other processes being unable to obtain execution permissions, the process scheduling in Erlang is soft and real-time, which ensures that all processes can obtain execution time as equal as possible.

Note: As mentioned above, there are no lightweight threads provided by the operating system in Linux. After a friend prompts, ucontext. H provides this facility.

Note: In Amazon recently, programming Erlang ranked 9th in the sales of computer science books and 935th in all books. It has obviously attracted the attention of the industry. FP language is very old, but after 20 years of OO, FP still has an unstoppable charm. fp description algorithms are the most direct and efficient, ocaml can even catch up with C ++. Of course, there are still some gaps in Erlang. However, Joe recently launched the Erlang Upgrade Plan, and I believe it will play an important role in promoting the development of Erlang. A few days ago, I was going to buy it together with concurrent programming in Erlang (2nd edition). The total cost was over $80, and the result was delayed. The discount for the next day's bundled sales was gone. Now I am just out of stock, it was depressing to be sold for $500 million RMB.