标签：x86 类型 没有 根据 工作组 控制 water ... list
由于OpenCL在异构系统上进行计算，需要管理并调度多个设备，就需要在设备之间内部或外部进行数据交互以及同步。根据同步的类型，同步分为两部分：宿主机端同步和设备端同步。
设备端同步主要指同一个内核内不同线程之前的同步，主要用于保证数据的一致性。根据工作组的划分，可以细分为组内同步和全局同步。
OpenCL采用宽松的同步模型和内存一致性模型。通常来说，采用硬件实现能够最好的实现同步，但是作为一个跨平台的API,并不能完全实现这些特性。所以OpenCL的解决方案是让程序员明确的知道当前系统的状态，添加同步点，从而可以依据这些信息获取预期行为。
在x86(CPU)平台上，我们使用同步机制如果条件还未满足，我们可以使系统进入休眠等待条件满足。但是GPU上的线程与系统层级的线程不是一个概念，GPU的线程所占用的资源是固定的，不能释放的，这也就导致了如果不同的不同work group不能为同一个资源做同步，因为没有释放的概念，所以必然存在死锁的状态。所以只能组内同步。
组内同步的机制是barrier,即屏障，在组内所有的item没有到达这个barrier之前，所有的item是不想下执行的。
item1
| item2
| | item3
| | |
| 5s |4s | 3s
| | |
------------------------------ 所有达到 barrier之后，同时出发
| | |
| | | 目前OpenCL不支持与组内同步类似的全局同步方式（原因上方已经介绍）。可以通过global fence以及原子操作来达到目的。
OpenCL是基于任务并行，主机控制的模型，其中每一项任务都是数据并行的，具体通过使用和设备关联的线程安全的命令队列来实现。当然，内核、数据以及其他操作并不是简单调用来进行的，而是通过异步加入指定的队列中。
从宿主机角度来看，保证宿主机同步的要点有一下三条：
当然，根据所需要同步的计算设备的个数，可以分为单设备同步和多设备同步。
clFinish可以阻塞程序的执行直到命令队列中的所有命令都执行完成。但是这只是相当于在末尾加上了一个barrier。在中间加入barrier需要调用如下函数：
cl_int clEnqueueBarrier(
cl_command_queue command_queue
)等待事件，即将一个等待事件加入命令队列，只有这个等待事件满足以后，才能执行之后加入的命令，使用的命令如下：
cl_int clEnqueueWaitForEvents(
cl_command_queue command_queue,
cl_uint num_events,
const cl_event* event_list
)从变量定义上很好理解，不再赘述。
我们在进行网络访问或者进行IO读取的时候是如何进行阻塞与非阻塞的区分的呢，没错，往往是传入一个标志。对于OpenCL也是一样的，如：
clEnqueReadBuffer(que, CL_TRUEm....)上面这个示例的第二个参数就是指定这个函数是否是同步操作，如果为TRUE，那么就会阻塞直至拷贝完成，如果为FALSE，在设置完后不等拷贝完成，就会返回。
在之前我们已经了解到，使用事件只能在同一个上下文中实现同步。那么在不同的设备不同的上下文中如何实现同步呢，只剩下了一种方法，cFinish,等待另一个命令队列执行完成，之后的命令才能继续执行。如一个CPU一个GPU，两者需要互相访问彼此的数据，那么如何实现同步呢，如果CPU要访问CPU的数据，必须等待CPU当前的命令队列执行完成，不再占用内存，GPU才能进行访问。
版权声明：本文为博主原创文章，转载需声明为转载内容并添加原文地址。
原文地址：http://coderdock.com
标签：x86 类型 没有 根据 工作组 控制 water ... list
原文地址：http://blog.51cto.com/9598289/2060010
