[olofsonprojects] Portable thread local storage?
- From: David Olofson <david@xxxxxxxxxxx>
- To: olofsonprojects@xxxxxxxxxxxxx
- Date: Sat, 28 Nov 2009 02:37:08 +0100
I'm working on an audio processing framework [*] with an API in the style of
OpenGL and OpenAL. For various reasons (probably similar to those that led the
OpenGL and OpenAL designers to the same decision), I'm using integer names, as
opposed to pointers, to reference objects.
Now, I want to support multiple independent contexts, to allow things like
off-line rendering of sound effects and instrument waveforms, without
interfering with the realtime context playing music and sound effects.
(Especially important if you target multi-core machines and want to do some
heavy structured audio...)
Right now, I'm trying to decide how to deal with this. There are basically
three options:
1. Add an a2_MakeCurrent() call, to select the target context
for subsequent context related API calls. Integer names are
context local, and there are no context names or pointers
being passed to any normal API calls.
2. Encode the parent context of objects in the integer names.
(This is sort of like passing a context pointer around, but
you hide this by extracting the context out of other object
references that you'll need to use with any API "command"
call anyway.)
3. The standard "OOP" style solution: Explicitly pass a context
pointer to any API function that deals with a context.
Obviously, alternative 3 makes the API more cumbersome for no apparent reason,
especially considering that very few, if any, applications will ever juggle
context in a way that motivates marking each call with the target context!
The second alternative is rather sexy from the API point of view: Never worry
about contexts except when dealing with other objects; the objects have
globally unique names and they know where they belong! However, it adds some
overhead (grabbing some bits and indexing the context object address out of a
table...), and there is a risk of it imposing significant limits on the number
of simultaneous contexts and/or objects you can use.
"No one will ever need more than 256 contexts and 16.7M objects per context!"
- if you catch my drift.
Of course, there are countless ways one could implement a name pool like that,
including just mapping up to 4G names to objects, where each object has a
pointer to it's parent context. However, a global pool brings in threading
issues, which can be avoided by encoding context index in the names,
effectively splitting the pool into N independent partitions.
Hmmm... Maybe I could just use more name bits for "context index" and wire
multiple context indexes to the same context if I run out of object names?
Alternative 1 may seem like the obvious choice, as this is how OpenGL, OpenAL
and probably some other similarly styled APIs do it. It even appears trivial
to implement - but here be dragons! For this to work in multithreaded
applications (thus actually making it *useful* in this case!), one needs to
use thread local storage to tell calls from different threads apart. I know
most C compilers and platforms implement this one way or another (syntactical
differences), but how portable and reliable is it, really...?
Any suggestions?
[*] Yes, I'm working on Audiality 2, or more specifically, A2::Core,
a minimal infrastructure, over which I'll build a total
replacement for Audiality/"the Kobo Deluxe Sound Engine".
--
//David Olofson - Developer, Artist, Open Source Advocate
.--- Games, examples, libraries, scripting, sound, music, graphics ---.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
'---------------------------------------------------------------------'
---------------------------------------------------------------------------
The Olofson Projects mailing list.
Home: http://olofson.net
Archive: //www.freelists.org/archives/olofsonprojects
Unsubscribe: email olofsonprojects-request@xxxxxxxxxxxxx subj:"unsubscribe"
---------------------------------------------------------------------------
Other related posts:
