云风的 BLOG

好多东西看不懂

好多东西看不懂

我不知道该说点啥

你的DEFAULT_QUEUE_SIZE设定为64
global_queue的head和tail类型都是uint32_t最大值为0xFFFFFFFF
而(0xFFFFFFFF+1)%64刚好为0
即uint32_t溢出后刚好模为0
因为看你文章刚好需要64K
所以想问DEFAULT_QUEUE_SIZE是你设计为64还是碰巧？= =
DEFAULT_QUEUE_SIZE的值需要刚好与(0xFFFFFFFF+1)模为零的吧
不然溢出后似乎结果会不正确

路过，留下点什么

@Cloud

看起来是不需要的。

另：
struct message_queue *
skynet_globalmq_pop() {
struct global_queue *q = Q;
uint32_t head = q->head;
uint32_t head_ptr = GP(head);
if (head_ptr == GP(q->tail)) {
return NULL;
}

if(!q->flag[head_ptr]) {
return NULL;
}

struct message_queue * mq = q->queue[head_ptr];
if (!__sync_bool_compare_and_swap(&q->head, head, head+1)) {
return NULL;
}
q->flag[head_ptr] = false;

return mq;
}

这里q->flag[head_ptr]=false也有延迟。如果获取队列的线程自己处理这个队列的消息话，这个不会引发一致性问题，然而，如果这个队列后来被交接给别的线程处理，则会引发一致性问题，因为那个接收的线程可能很块处理完消息，然后又有很快把消息队列放如global q, 那么你最初获取这个队列的线程对这个q->flag[head_ptr] = false执行就太滞后了，覆盖了那个线程设置为true的结果。不过在X86上可能不会发生，因为写总是顺序的。当把队列交付给别的线程时，总会发生内存写。
而你已经写了flag为false.

看来这个情况，在你的程序里不会发生。

@David Xu

我在

q->flag[tail] = true;

之后加了一句

__sync_synchronize();

之前似乎出现过读不到这个标记的情况.

不过

if(!q->flag[head_ptr])

之前加

__sync_synchronize();

应该没有特别的必要.

Lock-less的代码是很难做对的，特别是对于memory order以及可见性是很难掌控而且各种体系结构之间也有区别，移植性方面存在不确定。
例如，在X86上读是可以乱序执行的，写是顺序的，但是也要在编译器不重新安排指令顺序的情况下。
static void
skynet_globalmq_push(struct message_queue * queue) {
struct global_queue *q= Q;

uint32_t tail = GP(__sync_fetch_and_add(&q->tail,1));
assert(!q->flag[tail]);
q->queue[tail] = queue;
__sync_synchronize();
q->flag[tail] = true;
}
象q->flag[tail]=true就不保证别的CPU是立刻可见的，它可能被CPU内部的write buffer queue缓冲。除非你在后面跟上一句write memory barrier，迫使write buffer queue被刷出去。否则很可能存在写延迟，导致一致性问题或者效率问题。

struct message_queue *
skynet_globalmq_pop() {
struct global_queue *q = Q;
uint32_t head = q->head;
uint32_t head_ptr = GP(head);
if (head_ptr == GP(q->tail)) {
return NULL;
}

if(!q->flag[head_ptr]) {
return NULL;
}

象这种语句，CPU不保证读的顺序，它很可能在读出q->tail之前先读出q->flag[head_ptr]。除非你在中间插入read memory barrier.

没有等待的忙轮询式SPINLOCK也可能导致低效率和消耗过度的电能。用户态SPINLOCK通常被实行成spin几百个循环，然后进内核等待。spin循环中还插入电能节省代码，X86有pause指令，执行一条pause指令可让CPU暂时下降电能的消耗。更加积极的SPINLOCK的实现，还实行指数级的退避，当LOCK是上锁的时候，线程以指数方式退避，防止CACHE LINE在各CPU之间不停地PING-PONG，cmpset指令会导致PING-PING，无辜消耗电能和占用CPU之间的通讯带宽。
不阻塞的SPINLOCK， 如果锁的拥有者被抢先，那么别的线程将无限制地spin，最糟糕的情况下，会消耗很多的CPU时间。例如拥有者和需要锁的线程在同一个CPU上运行，当后者抢先了前者时，可能需要一个调度的时间片来降低自己的动态优先级，让前者机会跑起来，然后释放锁拱后者使用。

无论是Linux还是FreeBSD都可以在初始化pthread_mutex时设置是否为spin lock，他们的内部实现都是spin多少个周期，然后进入睡眠。

Linux和FreeBSD都不是公平锁的mutex，公平锁是先进先出的，而 Linux和FreeBSD 不保证这种次序。
需要实现这样的锁时，可以使用他们的mutex，然后自己建立先进先出队列，这样可以把不公平性降到最低。

并发问题 真是头疼

也要看是做什么的线程，保证不阻塞的情况下才是这样。
>
在有限处理器核心的机器上，开太多线程是降低了处理器效率，应考虑线程池，保证处理器核心数和活跃线程数基本一致最好，实在没必要开成百线程

呵呵,我并不同意 ccc 的看法,现在已经出问题了,就要解决问题,而现在是解决问题的同时重构了下,这些事情还是不要太晚做的好.

优化与否是一个不能用教条来判定的问题。

组播这个特性就是优化的产物，否则把需要发给多个对象的消息用循环依次发送出去即可。

如果组播这个特性必须存在，那说明它是用来解决一个性能热点的。其实现就必须被很好的优化。否则整个模块就不需要被实现。

程序设计第一原则：能不优化时就尽量不要优化。

你看看你没事就优化，结果增加了工作量。而且看你的描述，这个优化还增加了模块之间的耦合度。

在有限处理器核心的机器上，开太多线程是降低了处理器效率，应考虑线程池，保证处理器核心数和活跃线程数基本一致最好，实在没必要开成百线程

这个地方如果用互斥锁，性能上会差多少？