服务器开发中，为了充分利用多核甚至多个cpu，或者是简化逻辑编写的难度，会应用多进程（比如一个进程负责一种逻辑）多线程（将不同的用户分配到不同的进程）或者协程（不同的用户分配不同的协程，在需要时切换到其他协程），并且往往同时利用这些技术比如多进程多线程。
一个经典的服务器框架可以说如下的框架：
而这些服务器进程之间协同配合，为用户提供服务，其中中心服务器提供集群的调度工作，而逻辑服可以是逻辑服务器1提供登录服务、逻辑服务器2提供购买服务；也可以是2个服务器提供相同服务，然后视负载用户数将不同用户分配到不同服务器。
而这些服务器为了方便开发往往会采用到多线程的技术，一个经典的模式就是多个网络线程处理网络事件，然后一个线程处理用户逻辑；更进一步还可以是多线程处理用户逻辑，在多线程下比较麻烦的一点是不同线程访问同一个资源时需要加锁，不过众所周知锁上万恶之源，带来了难查的死锁和低下的问题。不过这些都有特殊的技巧可以解决，比如死锁，对同一线程重复获取同一把锁导致的死锁，我们可以采用可重入的计数锁，当一个线程获取了这把锁后，如果其他线程尝试lock这个mutex时会进入系统的调度队列，而本线程获取这把锁则会引用计数+1，本线程解锁则-1，如果引用计数为0则解锁，实现一个这样的锁，具体的算法的伪代码大致如下:
// int getthreadid() 获取线程ID
// switchtothread() 切换线程
// wakeup(int id) 唤醒线程
// bool exchange(bool * m, bool v) 原子的修改一个类型为bool变量的值，并且返回原有的值
// bool load(bool * m) 原子的获取一个bool变量的值
struct mutex{
mutex(){
islock = false;
lockid = -1;
ref = 0;
}
bool islock;
volatile int lockid;
int ref;
std::que<int> waitth;
};
void lock(mutex & mu){
int id = getthreadid();
if (id != mu.lockid){
if (exchange(&mu.islock, true)){
waitth.push(id);
switchtothread();
}
else
{
lockid = id;
}
}
else
{
ref++;
}
}
void unlock(mutex & mu){
int id = getthreadid();
if (id == mu.lockid)
{
if (--ref == 0){
wakeup(mu.que.pop());
}
}
}
这样的一组伪代码，其中关于原子操作和线程调度的实现在windows大致如下：
int getthreadid(){
return (int)GetCurrentThread();
}
int switchtothread(){
return SwitchToThread();
}
int wakeup(int id){
return ResumeThread((HANDLE)id);
}
boost中就提供了可重入的mutex: boost::recursive_mutex，windows中的Mutex和Critical Section就是可重入的，而linux的pthread_mutex_t就是不可重入的。
而因为同时访问2个资源导致的死锁，一个可以采用对资源的访问采用同一顺序访问，即可回避。
对于锁带来的性能问题，一个取巧的做法则每个用户数据独立，对公共资源的访问则采用一些高效的算法比如rcu、比如无锁算法
比如一个多读多写且读请求大于写请求的场合，我们就可以采用rcu算法。
rcu算法是在读的时候直接读数据，而写入则获取一份读拷贝在本地修改，并注册一个写入的回调函数，在读操作全部完成后调用回调函数完成写入。写操作之间则使用传统的同步机制。
而无锁算法，比较经典的则是一些无锁队列，比如ms-que，optimistic-que
ms-que的原理是利用原子操作，在写入的时候，先创建一个新的节点，完成数据的写入，然后在尾部利用cas操作，将尾节点的next指针指向新的节点，并将尾节点指向新节点。
在读的时候则是利用cas操作，将头节点指向头节点的next节点。
但是在利用这些，虽然充分利用了cpu的性能，但是编程也带来了极大的不便，比如多线程下不利于扩展以便充分利用集群提高性能的问题，多进程下则是复杂的异步调用。
一个理想的情况就是在跨进程通信的情况下，可以在发起一次远程的请求后，原地等待远端的相应，然后继续执行，比如在多线程的情况下，可以一个用户一个线程，然后在一次send之后，调用recv在请求返回后在继续执行，
但是多线程的调度会带来巨大的调度开销，这种情况下，更轻量级的协程成为了一个更好的选择，一个用户一个协程，然后在发起一次远程的请求后，切换到其他被唤醒的用户协程继续执行，在这个协程的请求返回后则唤醒这个协程继续执行逻辑代码。
协程带来的问题是协程是有用户控制调度的，所以用户需要自己实现调度算法，以及对应的锁算法（因为多协程虽然可以是单线程内执行，但是因为不同协程间的资源争用所以锁还是需要，而且是同步执行逻辑，如果使用spinlock则意味着整个系统阻塞，在异步网络id下即便是网络事件也不会被响应）。
协程的调度如下：
context::context* scheduling::onscheduling(){
context::context * _context = 0;
{
while (!time_wait_task_que.empty()){
uint64_t t = timer::clock();
time_wait_handle top = time_wait_task_que.top();
if(t > top.handle->waittime){
time_wait_task_que.pop();
uint32_t _state = top.handle->_state_queue.front();
top.handle->_state_queue.pop();
if (_state == time_running){
continue;
}
_context = top.handle->_context;
goto do_task;
}
}
}
{
while (!in_signal_context_list.empty()){
context::context * _context_ = in_signal_context_list.front();
in_signal_context_list.pop();
actuator * _actuator = context2actuator(_context_);
if (_actuator == 0){
continue;
}
task * _task = _actuator->current_task();
if (_task == 0){
continue;
}
if (_task->_state == time_wait_task){
_task->_state = running_task;
_task->_wait_context._state_queue.front() = time_running;
}
_context = _context_;
goto do_task;
}
}
{
if (!_fn_scheduling.empty()){
_context = _fn_scheduling();
goto do_task;
}
}
{
if (!low_priority_context_list.empty()){
_context = in_signal_context_list.front();
in_signal_context_list.pop();
goto do_task;
}
}
do_task:
{
if(_context == 0){
actuator * _actuator = _abstract_factory_actuator.create_product();
_context = _actuator->context();
_list_actuator.push_back(_actuator);
}
}
return _context;
}
锁算法原理recursive_mutex一样，当获取锁失败则将当前协程调度到其他用户协程，在解锁时唤醒等待协程
void mutex::lock(){
if (_mutex){
_mutex = true;
} else {
_service_handle->scheduler();
}
}
void mutex::unlock(){
if (_mutex){
if (!wait_context_list.empty()){
auto weak_up_ct = wait_context_list.back();
wait_context_list.pop_back();
_service_handle->wake_up_context(weak_up_ct);
}
_mutex = false;
}
}