Think of the game server concurrency by the Go language concurrency model

This period of time to see some of the go language-related things, found that the largest feature of the go language concurrency model similar to the C + + thread pool, just our Project Server is also used by the thread pool, recorded.

The concurrency unit of the Go language is the language built-in, using the keyword go+ function to create a new process, the newly created process will be automatically added to the scheduling context of the waiting schedule queue, a co-scheduling context corresponding to a thread, a co-scheduling context corresponding to a number of co-processes. The newly added coprocessor dynamically loads into each scheduling context, and if the average load of all scheduling contexts is high, the total scheduler automatically creates new threads and corresponding dispatch contexts for work. On the whole, it is n threads: N Dispatch Context: The relationship of M-covariance.

Our Project Server threading architecture uses Boost::threadpool as the underlying, starts ThreadPool with the number of threads configured, drives all invoker units, and each invoker drives its own service operation. A single service can hold one or more invoker. Adding the invoker layer between the ThreadPool and the service provides a clearer logic that implements the concept of service (parent) and serviceexec (child).

Essentially, both the go language and our thread pool +service structure implement the N-to-m mapping of the thread to the logical body, and the logic layer completely shields off the thread concept. The difference is that the execution of the Go language is based on the co-process, the co-process switching is the user state switch, and our service switching is the operating system thread switching, there will be a lot of cost. The go language is built-in to support concurrency, so details like smart loads are more powerful than the C + + thread pool. A thread pool in which experienced C + + programmers can be reasonably harnessed is a keyword used in the Go language, and the productivity boost that language brings is huge.

Looking at the inter-thread communication, the go language uses the built-in channel (Chan) type, and our project writes a set of service-to-message communication, essentially a messaging-based communication model.

We are using a Message Queuing polling mechanism, each service holding a std::list,service between a message passing through ServiceManager relay, the service in the heartbeat out of the list inside the message and processing, because it is a shared variable between threads, So read add messages are locked.

For the go language with the cache channel, before the channel cache queue full, to the channel plug data is non-blocking operation, the channel cache is not empty, the data from the channel is also non-blocking operation, these two cases are similar to our message, The difference is that the channel of the Go language is blocking operations when the cache is full and the cache is empty, which means that the Go language channel has synchronous semantics, and our message does not have this function. Of course, I think as a game server does not need to synchronize between threads, based on the polling message processing mechanism is fully sufficient. The power of the Go language channel is that each channel maintains the plug data coprocessor queue and the fetch data coprocessor queue, which greatly expands the channel's ability to really achieve the purpose of the channel will be different Chengliantong.

After looking at the go language, really feel that the use of the development of online games server is too appropriate, the co-process has advantages in concurrency, development efficiency will be much higher than C + +, and execution efficiency is said to be not too much decline, and language grammar are very and my appetite.

Think of the game server concurrency by the Go language concurrency model