
    <para>
      <!-- ext. spec p. 59 --> In order to ensure data integrity, the application is responsible
      for synchronizing access to shared CL/GL objects by their respective APIs.  Failure to
      provide such synchronization may result in race conditions and other undefined behavior
      including non-portability between implementations.
    </para>

    <para>
      <!-- ext. spec p. 59 --> Prior to calling <function>clEnqueueAcquireGLObjects</function>,
      the application must ensure that any pending GL operations which access the objects
      specified in <varname>mem_objects</varname>  have completed.  This may be accomplished
      portably by issuing and waiting for completion of a <function>glFinish</function>
      command on all GL contexts with pending references to these objects.  Implementations
      may offer more efficient synchronization methods; for example on some platforms calling
      <function>glFlush</function> may be sufficient, or synchronization may be implicit within
      a thread, or there may be vendor-specific extensions that enable placing a fence in the
      GL command stream and waiting for completion of that fence in the CL command queue. Note
      that no synchronization methods other than <function>glFinish</function> are portable
      between OpenGL implementations at this time.
    </para>

    <para>
      <!-- ext. spec p. 59 --> Similarly, after calling
      <function>clEnqueueReleaseGLObjects</function>, the application is responsible
      for ensuring that any pending OpenCL operations which access the objects specified
      in <varname>mem_objects</varname> have completed prior to executing subsequent GL
      commands which reference these objects. This may be accomplished portably by calling
      <citerefentry><refentrytitle>clWaitForEvents</refentrytitle></citerefentry> with the
      event object returned by <function>clEnqueueReleaseGLObjects</function>, or by calling
      <citerefentry><refentrytitle>clFinish</refentrytitle></citerefentry>.  As above, some
      implementations may offer more efficient methods.
    </para>

    <para>
      <!-- ext. spec p. 59 --> The application is responsible for maintaining the proper order
      of operations if the CL and GL contexts are in separate threads.
    </para>

    <para>
      <!-- ext. spec p. 59 --> If a GL context is bound to a thread other than the one in which
      <function>clEnqueueReleaseGLObjects</function> is called, changes to any of the objects in
      <varname>mem_objects</varname> may not be visible to that context without additional steps
      being taken by the application. For an OpenGL 3.1 (or later) context, the requirements
      are described in Appendix D ("Shared Objects and Multiple Contexts") of the OpenGL 3.1
      Specification. For prior versions of OpenGL, the requirements are implementation-dependent.
    </para>

    <para>
      <!-- ext. spec p. 59 --> Attempting to access the data store of an OpenGL object after
      it has been acquired by OpenCL and before it has been released will result in undefined
      behavior.  Similarly, attempting to access a shared CL/GL object from OpenCL before it
      has been acquired by the OpenCL command queue, or after it has been released, will result
      in undefined behavior.
    </para>

    <para>
      <!-- ext. spec p. 63 --> If the
      <citerefentry><refentrytitle>cl_khr_gl_event</refentrytitle></citerefentry> extension
      is supported, then the OpenCL implementation will ensure that any such pending OpenGL
      operations are complete for an OpenGL context bound to the same thread as the OpenCL
      context. This is referred to as implicit synchronization.
    </para>

<!-- 24-Oct-2011 -->