multithreading - Am I allowed to simultaneously render from the same buffer object on multiple shared contexts in OpenGL 2.1? -

in apple's documentation, read this:

• 1 — "shared contexts share texture objects, display lists, vertex programs, fragment programs, , buffer objects created before , after sharing initiated."
• 2 — "contexts on different threads can share object resources. example, acceptable 1 context in 1 thread modify texture, , second context in second thread modify same texture. shared object handling provided apple apis automatically protects against thread errors."

so expected able create buffer objects once, use them render simultaneously on multiple contexts. if that, crashes on nvidia geforce gt 650m backtraces this:

crashed thread:        10  dispatch queue: com.apple.root.default-qos exception type:        exc_bad_access (sigsegv) exception codes:       exc_i386_gpflt … thread 10 crashed:: dispatch queue: com.apple.root.default-qos 0  glengine  0x00007fff924111d7 glelookuphashobject + 51 1  glengine  0x00007fff925019a9 glebindbufferobject + 52 2  glengine  0x00007fff9243c035 glbindbuffer_exec + 127 

i've posted complete code @ https://gist.github.com/jlstrecker/9df10ef177c2a49bae3e. @ top, there's #define share_buffers — when commented out works fine, uncommented crashes.

i'm not looking debate whether should using opengl 2.1 — it's requirement of other software i'm interfacing with. nor looking debate whether should use glut — example code uses since it's included on mac , doesn't have external dependencies. nor looking feedback on performance/optimization.

i'd know if can expect able simultaneously render single shared buffer object on multiple contexts — , if so, why code crashing.

we ran 'glelookuphashobject' crash , made small repro-case (very similar yours) posted in 'incident' apple support. after investigation, apple dts engineer came following info, quoting:

"it came attention glflush() being called on both main thread , secondary thread binds position data. indeed introduce issues and, while subtle, indicate constraints place on threads , gl contexts aren’t being respected. @ point behoves either further investigate implementation ensure such situations avoided or, better yet, extend implementation explicit synchronization mechanisms (such offer gcd). "

so if run crash need explicit synchronization on application side (pending fix on driver-side).

summary of relevant snippets related "opengl, contexts , threading" official apple documentation:

[0] section: "use multiple opengl contexts" if application has multiple scenes can rendered in parallel, can use context each scene need render. create 1 context each scene , assign each context operation or task. because each task has own context, can submit rendering commands in parallel. https://developer.apple.com/library/mac/documentation/graphicsimaging/conceptual/opengl-macprogguide/opengl_threading/opengl_threading.html#//apple_ref/doc/uid/tp40001987-ch409-sw6  [1] section: guidelines threading opengl applications (a) use 1 thread per context. opengl commands specific context not thread safe. should never have more 1 thread accessing single context simultaneously. (b) contexts on different threads can share object resources. example, acceptable 1 context in 1 thread modify texture, , second context in second thread modify same texture. shared object handling provided apple apis automatically protects against thread errors. and, application following "one thread per context" guideline. https://developer.apple.com/library/mac/documentation/graphicsimaging/conceptual/opengl-macprogguide/opengl_threading/opengl_threading.html  [2] opengl restricts each context single thread each thread in os x process has single current opengl rendering context. every time application calls opengl function, opengl implicitly looks context associated current thread , modifies state or objects associated context. opengl not reentrant. if modify same context multiple threads simultaneously, results unpredictable. application might crash or might render improperly. if reason decide set more 1 thread target same context, must synchronize threads placing mutex around opengl calls context, such gl* , cgl*. opengl commands blockâsuch fence commandsâdo not synchronize threads. https://developer.apple.com/library/mac/documentation/graphicsimaging/conceptual/opengl-macprogguide/opengl_threading/opengl_threading.html