直接ByteBuffer和線程安全

Question

我學習的OpenGL ES，我看到了很多的分配直接ByteBuffer例子，然後把它包在FloatBuffer和Renderer#onDrawFrame(...)頂點數據寫入。

爲什麼這是線程安全的？ （或者是？）它是直接ByteBuffer的一個特性，還是由調用者onDrawFrame(...)完成的一些特性，可確保寫入緩衝區對着色器程序可見？

編輯：我對JMM的理解是，它是因爲Java暴露了現代硬件的一些複雜性。我假設在Java線程和訪問相同內存的非Java程序之間存在Java線程之間存在的相同內存可見性問題。我進一步假設着色器在GPU上運行，而不是在Java渲染線程中運行。

如果以上所有內容都是正確的，那麼必須在某處存在內存屏障以確保渲染線程中的寫入對着色器可見。我的問題歸結爲，內存屏障在哪裏？創建它是我的責任嗎？

Answer 1

理想情況下，所有的分配和填充都發生在渲染器線程上，所以沒有線程安全問題。在這方面，直接ByteBuffers沒有什麼特別之處。如果一個應用程序正在從一個線程寫入並從另一個線程讀取而沒有同步，則可能存在競態條件。

如果GLES驅動程序決定使用多個線程，它負責發出適當的內存障礙。

cf. Android SMP Primer

編輯（以匹配問題編輯）：應用程序的責任是在時間（我打電話了「渲染線程」）從一個線程訪問EGL上下文。如果您將數據從具有數據競爭的緩衝區提交給GLES，那麼您的時間將會很糟糕。只要渲染器線程具有一致的視圖，您在該線程上執行的所有操作都將按預期工作。

如果GLES實現恰好在不同的CPU線程或GPU中執行着色器，則GLES驅動程序有責任處理內存一致性問題。