Agent多线程同步开发指南.docVIP

Agent多线程同步开发指南 前言 目前的agent采用了多线程的实现方式，一方面提高了对大量并发的支持，另一方面引入了一些多线程程序特有的存储访问同步问题。 此文只介绍agent中可能出现基本的多线程同步问题，并列出对agent的优化和修改时，需要特别注意的地方。 另外，如果对agent增加新功能时引入了同步访问逻辑，也请更新此文档，保证此文档列出所有同步访问的地方。 基本问题 这里只简单介绍概念，并列出基本问题在agent中的应用，概念上的详细解释请参考操作系统、进程同步或线程同步的专业书籍。 如下问题假如出现，都会造成灾难性的后果。 读者-写者问题 简介： 读者-写者问题的读写操作限制 写-写互斥：不能有两个写者同时进行写操作 读-写互斥：不能同时有一个线程在读，而另一个线程在写。 读-读允许：可以有一个或多个读者在读。 在agent中的应用： 如果某存储正在被线程1读或写时，线程2释放（也是写的一种）此存储，就会造成内存访问问题，导致程序down掉。 所以，所有的同步读、写都需要先加锁，处理完后再解锁。 有一个例外（需要特别注意），析构时不能通过对自己加锁来处理同步调用，析构前必须保证此指针不会被别的线程访问，即需要从公共map中删除指针。 生产者-消费者问题 简介： 生产者将产品放入共享的缓冲，消费者从共享的缓冲取出产品。生产者必须等消费者取走产品后才能再放产品，消费者必须等生产者放入产品后才能去取。同一时间不能有两个消费者同时消费，同一时间也不能有两个生产者同时生成。 通过原子操作来保证生产消费的过程中，不出现重叠生产、重叠消费的情况。 在agent中的应用： 虚拟台处理时会遇到此问题，访问虚拟台map时，需要加锁，保证虚拟台座位数的消费时的查询和使用是原子操作，避免同一位置被2个玩家同时坐入（消费）的情况。 Gameserver产生的虚拟台数是有上限的，新增虚拟台时，需要判断。 哲学家就餐问题 简介： 哲学家就餐问题是操作系统中描述“并发操作”的一个经典例子：有5个哲学家，围坐在一张圆桌前，每个哲学家或者就餐或者思考．每个哲学家的左右都只有1只筷子，桌上总共只有5只筷子；而哲学家就餐时需要两只筷子，即其左右的筷子． 假如5个哲学家同时拿起右边的一只筷子，然后等待那左边的筷子，那么谁也等不到他左边的筷子，也就是就谁也不能吃饭，这种情况称为死锁 在agent中的应用： 定义程序运行过程中的顺序出现的t1,t2,t3时间点。 内存访问交叉时出现的死锁 线程1在t1时对gameservermap加锁，t2时对dealermap加锁，t3时间对gameservermap解锁； 线程2在t1时对dealermap加锁，t2时对gameservermap加锁，t3时间对dealermap解锁； 由于线程1在锁住gameservermap后请求锁dealermap时，需要等待线程2释放dealermap的锁，而线程2在锁住dealermap后需要等待线程1释放gameservermap，从而造成无限等待（就是死锁）； 内存访问和数据库访问交叉时出现的死锁 在数据库操作时，如果启动事务，那么在事务提交或回滚前，此事务中曾经根新过的表记录会被加锁。 所以，数据库操作的锁定机制，是和内存操作一样的，那么当数据库操作和内存操作出现交叉时，也会出现1.中演示过的死锁问题。 agent开发注意事项 现有的需要同步访问的存储 被同步访问得最多的几个存储 内存 contextMaplong, dealerContext* g_dealerMap; //存放荷官实例指针的容器 contextMaplong, clientContext* g_clientMap; //存放客户实例指针的容器 contextMaplong, captureContext* g_captureMap; //存放摄像头实例指针的容器 contextMaplong, gameContext* g_gameMap; //存放游戏服务实例指针的容器 contextMaplong, dataContext* g_dataMap; //存放游戏专用数据库服务实例指针的容器 contextMaplong, videoContext* g_videoMap; //存放视频服务实例指针的容器 contextMaplong, virtualContext* g_separateMap; //存放虚拟台实例指针的容器 contextMaplong, long g_virtMap; //存放虚拟台标识的容器 contextMaplong, virtualContext* g_errDecMap; /