Book recommendations on concurrency/async programming

[linpengcheng]

@seancorfield

It’s only “parallel” if every workshop is producing the same product at the same time otherwise it is “concurrent”.

At the same time in the same factory, some workshops produce the same product, some workshops produce different products, so parallel or concurrency is not the main point of the discussion here.

@seancorfield

In addition, inside the workshop, there are going to be multiple processes operating concurrently and, yes, those are absolutely asynchronous and they may well have to wait at times for either the inputs of the process to become available or for enough of the output of the process to be consumed in order to continue producing (backpressure).

They should definitely not be asynchronous, nor should there be waiting. If there is waiting in an operation (thread, asynchronous thread, fiber), it must be because the operation design or the proportion of system resource allocation is unscientific. If there are tasks (data) that are not completed, all workers (threads, asynchronous threads, fibers) are not allowed to wait. This is the most basic requirement of scientific management.

scientific management is committed to improving efficiency through operations research. It divides operations into indivisible monotonous operations (threads, asynchronous threads, fibers), and then designs the optimal combination of operations based on resources to achieve maximum efficiency. Among them, waiting is not allowed within an operation (thread, asynchronous thread, fiber), which is the most basic requirement, and this approach is also the most convenient for overall coordination and optimization. The most important design tool is the Gantt chart. The best implementation method is the warehouse/workshop model implemented by the factory, which is also the principle of ForkJoinPool (the basic technology of fiber), but the ForkJoinPool’s designer did not realize this and did not provide guidance in the ForkJoinPool’s user guide.

The most typical case: Amazon actually used AI to monitor and dispatch employees, which was inefficient and fired on the spot.

@seancorfield

Fire-and-forget is a dangerous path to tread because as throughput increases you need more and more threads – so you will either run out of resources (threads) or you will end up blocking, waiting for threads to become available, which is definitely inefficient and why languages and systems have moved away from fire-and-forget and have adopted more sophisticated approaches to handling concurrency and coordination between asynchronous processes.

They will not run out of resources (threads) or eventually block, because the warehouse (+ dispatch center = DBMS) will arrange the maximum number of workers (threads, asynchronous threads, fibers) in the system according to the optimal component (data) production ratio Quantity for production.

They are independent and do not interfere with each other. They are only responsible for doing their own work. There is no need to bother to observe and wait for resources during production. The warehouse (+ dispatch center = DBMS) is responsible for it.

This is consistent with the basic principle of ForkJoinPool.

• It uses an infinite queue to save tasks that need to be executed

• Use an internal queue to perform operations on tasks and subtasks that need to be executed to ensure their order of execution.

• ForkJoinPool can use a limited number of threads to complete a lot of tasks with a parent-child relationship

• Split a “big task” into multiple “small tasks” and hand the task to ForkJoinPool to execute

@seancorfield

It’s somewhat of an irony that all the pain and patterns and workarounds we’ve adopted on the JVM for the limited capacity of threads will be mostly unnecessary once we have Project Loom available and we can pretty much treat threads (fibers) as an unlimited resource!

There is no direct relationship between fibers and asynchrony.

A fiber is made of two components — a continuation and a scheduler. As Java already has an excellent scheduler in the form of ForkJoinPool, fibers will be implemented by adding continuations to the JVM.

ForkJoinPool uses the warehouse/workshop model and the scientific management of operations research, which has been mentioned above.

Fiber is more like an uber driver, not an uber employee (system thread). It does not need to bear the minimum wage, paid sick leave and unemployment benefits and other benefits, and there is no cost. Therefore, uber can almost treat the uber driver (fiber) as an unlimited resource, and dispatch the uber driver (fiber) to complete the task.

Conclusion

I just object to waiting in a thread, thinking that the waiting point is the natural boundary of the thread, and the thread should be terminated when there is a wait. The processing after the waiting point is solved by the dispatch center issuing new threads as needed.