rt,workman 进程是单线程么,就是轮询和执行回调, 是会冲突么?
如果我只启动一个进程的话, 是不是无论timer 还是 onmessage 中的回调,
都是按顺序一个一个执行的,处理数据都不需要加锁?
还是 onMessage 之间会同时访问相同的数据?
谢谢~~~以前用c++, 刚开始接触php开发游戏服务器, 考虑的互斥有些多
多进程单线程,轮询和回调不会冲突
如果我只启动一个进程的话, 是不是无论timer 还是 onmessage 中的回调, 都是按顺序一个一个执行的,处理数据都不需要加锁? 还是 onMessage 之间会同时访问相同的数据?
对,顺序执行,不需要加锁。
补充问一下,如果保证了用户只在一个进程通信的话,这个用户无论并发多少请求,实际上都是同步执行的吗,比如在这个进程内为用户实例化了一个角色对象,针对角色对象内的属性更改,背包数据增删改,都不需要加锁防止并发修改对吧,肯定是一个信息过来处理完了才会处理下一个信息吗
目前就是把角色的一些属性冗余到了内存中(globaldata能保证原子性的情况下数据结构太简单无法满足使用),之前用了mysql的get_lock来加锁处理,写了一半才想起来,对用户来说mysql链接一直是一个,所以这个锁现在加了和没加一样,所以在考虑是不是要自己加一个内存的锁来保证数据完整,但是如果用户自己不会并发处理数据的话,那么我完全也不需要考虑加锁问题了,麻烦给解答一下
另外上面说的是 用户自己对自己资源的争夺问题
还有一个问题就是 全服游戏玩家,这时候涉及到多个进程了,如果先不谈多个进程,只谈一个进程,那么在同一个进程内的多个玩家,是否也是同步执行的逻辑,不会有资源争抢的问题,一个进程内所有的消息回调 处理都是同步的吗,这样的话共同去修改内存的某个数据是否保证是原子性的
一个进程内的所有业务逻辑都是串行的,一个进程内的业务代码不会有并发执行的情况。如果保证了用户只在一个进程通信,无论并发多少请求,实际上都是同步执行的。如果角色对象的属性是内存的变量,则不需要加锁。如果角色对象的属性存储在外部存储中,并且没有其它进程操作这些属性也不需要加锁,否则需要。
多个用户也是一样的情况,单个进程内业务代码不会并发执行,都是串行的,不会有并发操作内存变量的问题。操作外部存储的时候仍然需要考虑多个进程并发操作的情况。
多进程单线程,轮询和回调不会冲突
对,顺序执行,不需要加锁。
补充问一下,如果保证了用户只在一个进程通信的话,这个用户无论并发多少请求,实际上都是同步执行的吗,比如在这个进程内为用户实例化了一个角色对象,针对角色对象内的属性更改,背包数据增删改,都不需要加锁防止并发修改对吧,肯定是一个信息过来处理完了才会处理下一个信息吗
目前就是把角色的一些属性冗余到了内存中(globaldata能保证原子性的情况下数据结构太简单无法满足使用),之前用了mysql的get_lock来加锁处理,写了一半才想起来,对用户来说mysql链接一直是一个,所以这个锁现在加了和没加一样,所以在考虑是不是要自己加一个内存的锁来保证数据完整,但是如果用户自己不会并发处理数据的话,那么我完全也不需要考虑加锁问题了,麻烦给解答一下
另外上面说的是 用户自己对自己资源的争夺问题
还有一个问题就是 全服游戏玩家,这时候涉及到多个进程了,如果先不谈多个进程,只谈一个进程,那么在同一个进程内的多个玩家,是否也是同步执行的逻辑,不会有资源争抢的问题,一个进程内所有的消息回调 处理都是同步的吗,这样的话共同去修改内存的某个数据是否保证是原子性的
一个进程内的所有业务逻辑都是串行的,一个进程内的业务代码不会有并发执行的情况。如果保证了用户只在一个进程通信,无论并发多少请求,实际上都是同步执行的。如果角色对象的属性是内存的变量,则不需要加锁。如果角色对象的属性存储在外部存储中,并且没有其它进程操作这些属性也不需要加锁,否则需要。
多个用户也是一样的情况,单个进程内业务代码不会并发执行,都是串行的,不会有并发操作内存变量的问题。操作外部存储的时候仍然需要考虑多个进程并发操作的情况。