1.同步類型

  根據同步的類型，同步分為兩部分：宿主機端同步和設備端同步。

2.設備端同步

  設備端同步主要指同一個內核內不同線程之前的同步，主要用於保證數據的一致性。根據工作組的劃分，可以細分為組內同步和全局同步。

2.1組內同步

  OpenCL采用寬松的同步模型和內存一致性模型。通常來說，采用硬件實現能夠最好的實現同步，但是作為一個跨平臺的API,並不能完全實現這些特性。所以OpenCL的解決方案是讓程序員明確的知道當前系統的狀態，添加同步點，從而可以依據這些信息獲取預期行為。

  在x86(CPU)平臺上，我們使用同步機制如果條件還未滿足，我們可以使系統進入休眠等待條件滿足。但是GPU上的線程與系統層級的線程不是一個概念，GPU的線程所占用的資源是固定的，不能釋放的，這也就導致了如果不同的不同work group不能為同一個資源做同步，因為沒有釋放的概念，所以必然存在死鎖的狀態。所以只能組內同步。

  組內同步的機制是barrier,即屏障，在組內所有的item沒有到達這個barrier之前，所有的item是不想下執行的。

  item1
    |       item2
    |         |       item3
    |         |         |
    | 5s      |4s       | 3s
    |         |         |
------------------------------ 所有達到 barrier之後，同時出發
    |         |         |
    |         |         |
 

2.2全局同步

  目前OpenCL不支持與組內同步類似的全局同步方式（原因上方已經介紹）。可以通過global fence以及原子操作來達到目的。

3.宿主機端同步

  OpenCL是基於任務並行，主機控制的模型，其中每一項任務都是數據並行的，具體通過使用和設備關聯的線程安全的命令隊列來實現。當然，內核、數據以及其他操作並不是簡單調用來進行的，而是通過異步加入指定的隊列中。

  從宿主機角度來看，保證宿主機同步的要點有一下三條：

• 調用clFinish函數，該函數將阻塞直至命令隊列中的所有命令都執行完畢。
• 等待一個特定事件的完成
• 執行一個阻塞操作

當然，根據所需要同步的計算設備的個數，可以分為單設備同步和多設備同步。

3.1單設備同步

3.1.1設置barrier

clFinish可以阻塞程序的執行直到命令隊列中的所有命令都執行完成。但是這只是相當於在末尾加上了一個barrier。在中間加入barrier需要調用如下函數：

cl_int clEnqueueBarrier(
  cl_command_queue command_queue
  )

3.1.2等待事件

  等待事件，即將一個等待事件加入命令隊列，只有這個等待事件滿足以後，才能執行之後加入的命令，使用的命令如下：

cl_int clEnqueueWaitForEvents(
  cl_command_queue command_queue,
  cl_uint num_events,
  const cl_event* event_list
  )

從變量定義上很好理解，不再贅述。

3.1.3阻塞訪問

  我們在進行網絡訪問或者進行IO讀取的時候是如何進行阻塞與非阻塞的區分的呢，沒錯，往往是傳入一個標誌。對於OpenCL也是一樣的，如：

clEnqueReadBuffer(que, CL_TRUEm....)

上面這個示例的第二個參數就是指定這個函數是否是同步操作，如果為TRUE，那麽就會阻塞直至拷貝完成，如果為FALSE，在設置完後不等拷貝完成，就會返回。

3.2多設備同步

  在之前我們已經了解到，使用事件只能在同一個上下文中實現同步。那麽在不同的設備不同的上下文中如何實現同步呢，只剩下了一種方法，cFinish,等待另一個命令隊列執行完成，之後的命令才能繼續執行。如一個CPU一個GPU，兩者需要互相訪問彼此的數據，那麽如何實現同步呢，如果CPU要訪問CPU的數據，必須等待CPU當前的命令隊列執行完成，不再占用內存，GPU才能進行訪問。

版權聲明：本文為博主原創文章，轉載需聲明為轉載內容並添加原文地址。

原文地址：http://coderdock.com

OpenCL-3-同步機制