GLAF
OpenGL Advanced Functionality
 

News   What is?   Pros and Cons  Motivation   History   Features  Basic Use   Multithreading  Platforms Take Care!  To Do   Download


Notes about multithreading
  • First of all, if your application uses non-shared processes rather than threads, you don't need any special considerations since the GLAF internal contexts data won't be shared across processes.
  • If your application has several threads (or share-group processes created through 'sproc') but only one of them is used for GLAF and for OpenGL rendering in all contexts, you don't need special considerations either.
  • If your application uses a different thread (or share-group process created through 'sproc') for each OpenGL context, but you just need one GLAF context (see 'Alternative contexts management' at the 'Basic Use' page for details on what situations let you use one GLAF context for several OpenGL contexts), you don't need special considerations either (ie, GLAF is thread-safe in this case, except the emulation mode of Copy Texture, so you may want to call glaf_IsCopyTextureNative for knowing whether Copy Texture is emulated or not).
  • Otherwise,  if each thread in your application needs to call glaf_ReadyForContext, you need to provide some locking/unlocking: First, creation and destruction of GLAF contexts should be locked. Second, you should lock all the work of one thread since before it calls glaf_ReadyForContext until the last call to a GLAF function in the current redraw. Note that this may increase your performance rather than decreasing it, because this locking will lower the number of context switches, and so, in general, increase OpenGL performance, which is not usually tuned for a zillion of context switches per second.
  • If for some reason you really need a reentrant GLAF for all situations, please contact me.

 
News   What is?   Pros and Cons  Motivation   History   Features  Basic Use   Multithreading  Platforms Take Care!  To Do   Download

Copyright (C) 2001-2005 César Blecua Udías