初级会员
  • 第 28050 位会员
  • cyinx
  • 2018-12-29 11:34:11
  • Offline
  • 19 58

最近发布的文章

    暂无

最近分享的资源

    暂无

最近发布的项目

    暂无

最近的评论

  • #20 @bobohume LMAX的disruptor么? disruptor在多消费者多生产者的情境下性能本来就不高,单消费者单生产者的情况下才实现了无锁,这个队列类似于linux的内核的一个队列,kfifo.h源文件中.生产者消费者队列,优化性能的重点不在于选择什么样的锁,而在于如何解决频繁调用锁.即便你锁的消耗很低,但是每次出队都要调用锁,性能一样上不去.就算使用互斥锁,每次锁消耗时间很长, 但是每次出队100个item,那么平均到单次操作消耗也很低.
  • 14楼 @bobohume 我觉得你还是删了这条回复比较好,不然可能会暴露你对操作系统多线程并发与同步这块知识点的理解能力......多看多理解,比如,想一下锁在操作系统和CPU中是怎么实现的,再想一下信号量是怎么实现的.再想一下信号量是干什么的,锁是干什么的.再想一下锁唤醒机制与信号量唤醒机制.
  • #11 @bobohume golang 1.11 源代码runtime\chan.go:181行 channel使用lock的地方.这个lock就是lock_sema.go实现的.而golang标准库提供的sync/mutex包也是使用lock_sema.go实现的lock.这个就是乐观互斥锁.我不知道"channel锁比外面的cas 无锁队列要强的"这个结论是怎么得出来的.或者说你根本没有看过channel的源代码.
  • 8楼 @bobohume "channel本身内部有锁。不过效率比较高点" 我不知道这个结论是怎么得出来的.锁就是锁,不同类型的锁可能性能有区别.但是消费者每次通过channel获取生产者数据,都需要经过锁.那么效率必定高不到那里去.channel如果能实现数据批量处理和队列不限长度,通过一次互斥操作来消耗大量生产者数据,那么锁的消耗就被拉平.或者以其他方式实现队列,比如类似于.NET framework的concurrentqueue采用segment加cas方式实现无锁.那么性能肯定会上去. 有一篇分析golang写的消息队列软件的文章.其中大量使用channel的那一款,性能也出现过瓶颈.
  • 我也是做了很多年C++游戏服务器,然后又用go来做游戏. 基本上最开始我也是迷信golang的channel goroutine和actor模式.但是后来我阅读了golang的源代码,发现channel也是加锁的.而且goroutine和channel数量太多,虽然吞吐上去了,但是逻辑处理延迟也增加了很多.因为大量使用异步操作造成了进程异步虚耗,很多逻辑的高延迟对于一般应用来说无所谓,但是对于游戏来说,可能无法接受.在后来使用golang的过程中,我尽量控制新建goroutine,减少channel的使用,采用事件循环的方式来构建的服务器.充分利用了golang的开发效率与便利的部署方式.又避免了异步灾难. 服务器框架也开源了.https://github.com/Cyinx/einx