Bug 1088 - OSX 10.9.5: Crash using master GLContext with multiple threads using GLContext sharing with master
Summary: OSX 10.9.5: Crash using master GLContext with multiple threads using GLContex...
Alias: None
Product: Jogl
Classification: JogAmp
Component: macosx (show other bugs)
Version: 2
Hardware: All macosx
: --- enhancement
Assignee: Sven Gothel
Depends on:
Reported: 2014-10-05 04:29 CEST by Sven Gothel
Modified: 2014-10-08 08:25 CEST (History)
0 users

See Also:
SCM Refs:
245605eb760f6c1301d58a252fb6465a064ae19f fe999abe4cb142b814e700d88e9f148ecb0ae4f0 5d3b7dc83c04e2c626a635eb3d143710f7ef4db2 73654365e6147a5eabe8747e5f4802b1fba83829
Workaround: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2014-10-05 04:29:57 CEST
On OSX 10.9.5, running multiple GLAutoDrawables each within their
own Animator while GLContext sharing one common master thread
w/o locking - leads to a crash.
Comment 1 Sven Gothel 2014-10-07 20:33:16 CEST
Related ARB_robustness:
 - https://www.opengl.org/registry/specs/ARB/robustness.txt,
   - Section Overview 
   - Paragraph 5

"Multi-threaded use of OpenGL contexts in a "share group" allow
sharing of objects such as textures and programs.  Such sharing in
conjunction with concurrent OpenGL commands stream execution by two
or more contexts introduces hazards whereby one context can change
objects in ways that can cause buffer overflows for another context's
OpenGL queries."
Comment 2 Sven Gothel 2014-10-07 21:32:27 CEST
On OSX 10.9.5 using multiple GLContext, sharing a common master,
each rendering in their own thread (multithreading),
causes a crash.

I added experimental locking of the ShareSet in
which removes the crash.
However, such ShareSet locking is too invasive:
  - may deadlocks multithreaded creation/usage,
    e.g. in GLMediaPlayerImpl (Animator vs StreamWorker)

  - removes benefits of multithreading usage

Further analysis:

- OSX 10.9.5 not always crashes utilizing multithreaded shared contexts

- GLMediaPlayerImpl does not crash due to proper use of RingBuffer*,
  which adds implicit lock-free object queuing (put/take).

- GearsES2 does crash due to concurrent draw commands of the 'slaves'
  using the 'master' VBO objects,
  even though such objects are created before concurrent read-only access
  and immutable afterwards.


- Adding new GLRendererQuirk.NeedSharedObjectSync

- _NOT_ handling this quirk in our API directly,
  i.e. not implementing above mentioned ShareSet locking.

- User is required to synchronize access of shared GL objects,
  for drivers exposing GLRendererQuirk.NeedSharedObjectSync

- Adding a note to GLSharedContextSetter


GLSharedContextSetter#synchronization GL Object Synchronization

Usually synchronization of shared GL objects should not be required, 
if the shared GL objects are created and immutable before concurrent usage.

However, using drivers exposing GLRendererQuirks.NeedSharedObjectSync
always require the user to synchronize access of shared GL objects.

Synchronization can be avoided if accessing the shared GL objects
exclusively via a queue or com.jogamp.common.util.Ringbuffer, 
see GLMediaPlayerImpl as an example.

Comment 3 Sven Gothel 2014-10-08 08:25:19 CEST
(*) == preliminary commits for unit testing 
       and providing a clean patch addressing the issue only.


245605eb760f6c1301d58a252fb6465a064ae19f (*)

Shared Gears* Unit Tests: Align all 3 Gears* implementation 
to use a shared Gears* object


fe999abe4cb142b814e700d88e9f148ecb0ae4f0 (*)

Bug 1088: Fix ant test target 'junit.run.sharedctx': 
Reuse generalized 'generic.junit.run.newt.headless', 'generic.junit.run.awt', ..


5d3b7dc83c04e2c626a635eb3d143710f7ef4db2 (*)

GLRendererQuirks: Align wording in API doc



Add GLRendererQuirks.NeedSharedObjectSync; Tests: Synchronize GL objects if GLRendererQuirks.NeedSharedObjectSync is set.

^^ actual fix, as described.