众所周知，对共享数据的同步和保护基本上都要用到锁。锁的种类也很多，如常用的互斥锁，读写锁，信号量，自旋锁等等。但用到锁，就会有阻塞，无论阻塞时间长短，都会对系统性能有一定影响，而这也恰恰是一些对实时性要求很高的产品所不允许的。这时，我们就会想到无锁操作。可是如何实现无所操作呢？
下面我就根据个人经历来分享一下，也算是对学习知识的一个总结。
问题背景
首先介绍下OpenEM。OpenEM 的全称是 Open Event Machine。是 TI 针对嵌入式应用开发的 multicore runtime system library。OpenEM 可以在多核上有效的调度，分发任务。它把任务调度给负载轻的核，进而实现动态的负载平衡。OpenEM 是基于 TI Keystone 系列芯片的 multicore Navigator 构建的，具有开销小，效率高的特点。
OpenEM是一个事件(event)驱动的调度机制,每次有事件分发给某个Core时，事件最终会被发送给这个Core的某个调度进程，这个进程则会调用相应的callback函数处理事件。我的问题就发生在这里。我的系统规定，每个事件处理的时间不能超过1ms，也就是调度进程调用callback函数的执行时间不能超过1ms，如果超过就会造成后续处理事件的delay,系统就会crash。
发生Delay的代码：
//Event Scheduler Process
event_callback()
{ ...
pthread_rwlock_rdlock(&(g_shmDataPtr->monLock)); //Delay occurs here
...
pthread_rwlock_unlock(&(g_shmDataPtr->monLock));
...
}
g_shmDataPtr指向的共享内存中存放了一些控制数据，我在多个进程中都会进行上述读操作。
//Process_Write
function_wr()
{ ...
pthread_rwlock_wrlock(&(g_shmDataPtr->monLock));
...
pthread_rwlock_unlock(&(g_shmDataPtr->monLock));
...
}
但是我只在Process_Write进程中对这块数据进行写操作。而且通常情况下该操作只会在系统启动时发生，当然如果有用户主动发送修改请求时，function_wr()也会被调用。
开始时，我怀疑是rdlock发生了阻塞，可能是之前有人发送了修改数据的请求而上了写锁导致的。于是我改用不会阻塞的trylock接口：
if (0 != pthread_rwlock_tryrdlock(&(g_shmDataPtr->monLock)))
{ return 0;/*没有获取锁返回成功，不影响系统功能*/}
可是系统跑了一段时间后测试还是失败。于是我测试了tryrdlock函数的执行时间，结果发现光是这个函数的执行时间有时候就有200us+。看来用锁是没办法满足现在系统对性能的要求了。
于是我上网查了关于无锁编程的一些资料，发现可以用原子量来进行数据的更新管理。这种方法很像是我们的代码的版本控制，修改和读取的数据总是存在两个不同的地方。于是我就把这种方法叫做版本控制，最终的实现方案如下：
//Event Scheduler Process
Atomic32* g_ActiveDataIndexPtr; /*指向原子变量的全局指针*/
DataStruct * g_aaTraceCtrlDataPtr; /*新开辟共享内存可以存放两份数据, 索引为0，1 */
event_callback()
{ ...
u32 actIndex = AtomicRead32(g_ActiveDataIndexPtr);
DataStruct *currentDataPtr = &g_aaTraceCtrlDataPtr[actIndex];
...
}
在读数据的地方，直接读取现在有效的数据索引。即使刚读完有效索引，索引就更新了，我们也只是使用了老的正确的数据。当下次再读时就可以读到更新后的数据了。
//Process_Write
function_wr()
{ ...
u32 currectActiveIndex = AtomicRead32(g_ActiveDataIndexPtr);
u32 backUpIndex = currectActiveIndex ? 0 : 1;
/*write new date in backup shm at first*/
...
/*after date already updated to backup shm, switch backup to active*/
AtomicSet32(g_ActiveDataIndexPtr,backUpIndex );
...
}
在写数据的时候，我们先在空闲的备份共享内存中更新数据，这样别的进程还在Active的共享内存中读数据，所以不会有任何冲突。等数据更新完，再把备份数据的索引变成有效索引，这样之后再被读取就用的是新的数据了。
这样就解决了性能的问题，但是缺点就是需要多一倍的控制数据存储空间。
当然，以上只是我的方法。如果文中有任何问题，请大家指出，共同学习，共同进步。：）
