Direct ByteBuffer 및 스레드 안전성

Question

OpenGL ES에 대해 배우고 있는데 직접 ByteBuffer을 할당 한 많은 사례를 본 다음 FloatBuffer에 랩핑하고 정점 데이터를 Renderer#onDrawFrame(...)에 작성합니다.

왜이 스레드로부터 안전한가요? (또는 그럴 수 있습니까?) 직접 ByteBuffer의 특성입니까, 아니면 호출자가 onDrawFrame(...)을 수행하여 버퍼에 쓰는 것이 쉐이더 프로그램에 표시되는지 확인해야합니까?

편집 : JMM에 대한 필자의 이해는 Java가 현대 하드웨어의 복잡성을 일부 노출시키기 때문에 그것이 무엇인지를 이해하는 것입니다. 나는 같은 메모리를 액세스하는 Java 스레드와 비 Java 프로그램간에 Java 스레드간에 존재하는 동일한 메모리 가시성 문제가 존재한다고 가정합니다. 나는 셰이더가 자바 렌더링 스레드가 아닌 GPU에서 실행된다고 가정합니다.

위의 내용이 모두 올바른 경우 렌더링 스레드의 쓰기가 쉐이더에 표시되도록 메모리 장벽이 있어야합니다. 내 질문은 아래로, 그 메모리 장벽은 무엇입니까? 그것을 만드는 것이 내 책임입니까?

Answer 1

이상적으로 모든 할당 및 채우기는 렌더러 스레드에서 발생하므로 스레드 안전성 문제는 없습니다. 이와 관련하여 직접적인 ByteBuffers에 특별한 것은 없습니다. 앱이 한 스레드에서 글을 쓰거나 동기화가없는 다른 스레드에서 읽는다면 경쟁 조건이 존재할 수 있습니다.

GLES 드라이버가 다중 스레드를 사용하기로 결정한 경우 적절한 메모리 장벽을 발행해야합니다.

cf. Android SMP Primer

편집는 (문제의 편집에 맞게) : 응용 프로그램의 책임은 (필자는 "렌더 스레드를"전화 했어) 한 번에 하나 개의 스레드에서 EGL 컨텍스트에 액세스 할 수 있습니다. 데이터 경주가있는 버퍼에서 GLES로 데이터를 제출하면 나쁜 시간이 생길 것입니다. 렌더러 스레드가 일관된 뷰를 가지고있는 한, 그 스레드에서 GLES로하는 모든 작업이 예상대로 작동합니다.

GLES 구현이 다른 CPU 스레드 또는 GPU에서 쉐이더를 실행하는 경우 메모리 일관성 문제를 처리하는 것이 GLES 드라이버의 책임입니다.