- 主题:lockfree的容器的cpu cache同步
最近用boost/ipc/spsc_queue,是个lockfree的队列,在用的时候,经常会发现有队列满,push不进队列的情况。开始以为是队列长度设得不够,但是发现即使把队列设得很长,还是会偶尔有队列满得情况。后来发现,如果producer和consumer两边都用aquire 和 release fence框起来,即使队列很短,也没有队列满的情况。难道lockfree之后,cpu cache同步需要自己加?
--
FROM 115.193.179.*
队列满,说明从队列取数据的效率低
队列不满,说明向队列加数据的效率低
当然,这种都是对照来看
【 在 ziqin 的大作中提到: 】
: 最近用boost/ipc/spsc_queue,是个lockfree的队列,在用的时候,经常会发现有队列满,push不进队列的情况。开始以为是队列长度设得不够,但是发现即使把队列设得很长,还是会偶尔有队列满得情况。后来发现,如果producer和consumer两边都用aquire 和 release fence框起来,即使队列很短,也没有队列满的情况。难道lockfree之后,cpu cache同步需要自己加?
--
FROM 114.245.201.*
我的意思是,在我的这个情况里,队列满不满不是加/取数据的效率问题,而是加/取数据两个进程所在的cpu cache同步到共享内存里的问题
【 在 Bernstein 的大作中提到: 】
: 队列满,说明从队列取数据的效率低
: 队列不满,说明向队列加数据的效率低
: 当然,这种都是对照来看
: ...................
--
FROM 115.193.179.*
队列的实现,应该就提供了同步机制,不需要自己再加
【 在 ziqin 的大作中提到: 】
: 我的意思是,在我的这个情况里,队列满不满不是加/取数据的效率问题,而是加/取数据两个进程所在的cpu cache同步到共享内存里的问题
:
--
FROM 114.245.201.*
咋确定不是效率问题的?
瞅了一下spsc_queue的实现,就是reader+writer线程针对两个atomic索引变量write_index_、read_index_搞的acquire/release操作,而且中间有刻意padding一下让这两个索引变量处于不同的cache line中。
队列中的每个对象所占的内存也是跟着atomic变量的acquire/release语义走的。
【 在 ziqin 的大作中提到: 】
: 我的意思是,在我的这个情况里,队列满不满不是加/取数据的效率问题,而是加/取数据两个进程所在的cpu cache同步到共享内存里的问题
:
--
修改:z16166 FROM 125.35.123.*
FROM 125.35.123.*
楼主,这个queue只能有一个
Producer和一个consumer
你看看是不是你有多个producer或者多个consumer
【 在 ziqin 的大作中提到: 】
: 最近用boost/ipc/spsc_queue,是个lockfree的队列,在用的时候,经常会发现有队列满,push不进队列的情况。开始以为是队列长度设得不够,但是发现即使把队列设得很长,还是会偶尔有队列满得情况。后来发现,如果producer和consumer两边都用aquire 和 release fence框起来,即使队列很短,也没有队列满的情况。难道lockfree之后,cpu cache同步需要自己加?
--
FROM 107.77.208.*