Inter-task communication model in multi-task environment

This was originally an email discussion between me and my friends. The core idea is how our programmers view locks and queues under the current multi-task model, and how to view the real-world solution of multi-process and multi-thread communication. In my speech video "tomorrow's world-programming requirements under the cloud computing model", I will make a summary here for your reference. Thank you for making a brick. The original article is as follows: for communication between different tasks under the multi-task development model, I have worked out some of my own routines over the years.
 
For inter-process communication, it is generally recommended to use the socket method. TCP and UDP can all be used. The main reason is that I regard a functional process as a service. Since it is a service, the maximum deployment flexibility should be maintained, and a large number of shared memory areas and semaphores should be used for synchronization. This will inevitably cause these processes to be deployed on one machine, so it is difficult to achieve load balancing in the future. Therefore, I created the npi concept and used the network address location information to calibrate the process access mode, in order to maintain deployment flexibility.
That is, a process is regarded as a service in a server cluster. The service is accessed using network interfaces to provide standard access capabilities and can be deployed on any server, as long as the caller can find the IP address and port of the service in an appropriate way, the caller can request the service and obtain the result based on the protocol.
Therefore, in recent years, I have abandoned all the process sharing schemes recommended by operating systems such as Unix and Windows and the COM interface. In my opinion, the cloud computing access model in the future will be more flexible and practical.
 
In terms of Inter-thread synchronization, I want to simplify it into two types of synchronization requirements:
1. synchronous to asynchronous, that is, a thread originally wanted to call the work of another thread, but it is not convenient to execute immediately, because it is easy to crash, so it needs to be synchronized to asynchronous. In this case, the recommended model is "queue + waiting thread", which is actually the working mechanism of Windows. Of course, based on the concept of resource lock, this queue, as a passive resource, needs to be made multi-thread secure.
2. asynchronous synchronization. A resource is called by multiple threads. For example, if a socket is used, multiple sending and receiving threads need to call the resource. We recommend that you use the lock model to lock the resource, all functional methods of the socket are protected. After that, the socket can be called a multi-threaded secure socket, and any number of threads will be called in the future.
 
The above is my abstract view of lock and queue after multi-task development.
 
Well, you are welcome to discuss and criticize it.
========================================================== ====================
Buy 0bug-C/C ++ commercial engineering at the reserve price online
Directly click the link below or copy it to the address bar of the browser)
Http://s.click.taobao.com/t_3? Latency % 3 Fpid % 3Dmm_13866629_0_0
Xiao

This article from the "Xiao blog" blog, please be sure to keep this source http://tonyxiaohome.blog.51cto.com/925273/273759