Question

In Linux kernel source code, there are many memory barrier(smp_mb() and so on).

But in redis’s source,I didn’t see it. In the Makefile of redis, gcc optimize option is -O2, so it should be reorder these instruction. Why it not use mb() for insure the correct behavior?

Added:

For example:
In Linux kernel’s kfifo:

unsigned int __kfifo_put(struct kfifo *fifo,unsigned char *buffer, unsigned int len)   
{   
  unsigned int l;   
  len = min(len, fifo->size - fifo->in + fifo->out);
  smp_mb();
  l = min(len, fifo->size - (fifo->in & (fifo->size - 1)));   
  memcpy(fifo->buffer + (fifo->in & (fifo->size - 1)), buffer, l);
  ...
  smp_wmb();
  fifo->in += len;
  ...
}

In Redis source, I research the whole project, cann’t find memory barriers:
for example:

zskiplistNode *zslInsert(zskiplist *zsl, double score, robj *obj) {
  zskiplistNode *update[ZSKIPLIST_MAXLEVEL], *x;
  unsigned int rank[ZSKIPLIST_MAXLEVEL];
  int i, level;
  ...
  level = zslRandomLevel();
  if (level > zsl->level) {
    for (i = zsl->level; i < level; i++) {
      rank[i] = 0;
      update[i] = zsl->header;
/////need a mb() ???
      update[i]->level[i].span = zsl->length;
    }
    zsl->level = level;
  }
  ...
}

is it special that why in redis there is no memory barriers?
I think it probably that my understand for mb() is immature, thanks for comment…

added:

But in above two pieces of code displayed, the kfifo in linux kernel uses mb(). it just changes variables allocated in thread’s stack space and also user mb() between r/w operation. So it should not totally relevent to multi-threading… (although redis is single thread)

Answer 1

Redis is single threaded, so there’s no need for memory barriers.

They’re only relevant if you have multiple execution paths (e.g. in a multithreaded application). Even with multithreaded user space applications, you would normally not need your own memory barriers, as libraries (e.g. pthreads) contains memory barriers in the synchronization APIs, (such as mutexes, semaphores, condition variables and so on).