[vorbis-dev] Thread issues: clarification

[Jeff Squyres]

Monty --

I'm still running into problems with my threaded encoded, and I think I
just figured out why.

I have N threads running in parallel calling vorbis_analysis_blockout()
and vorbis_analysis() to do the number crunching on the input samples.
They all share a single vorbis_dsp_state -- my understanding was that this
was ok; they only *read* from the vorbis_dsp_state, therefore not creating
any race conditions.

However, I think I must have misunderstood, because in reading the code
from vorbis_analysis_blockout() and the functions that it calls, it
appears that there are writers of the vorbis_dsp_state (or, more to the
point, writers to some of the subsidiary data structures).

_ve_envelope_search(), for example, seems to be a problem.  It can realloc
some data associated with the envelope_lookup.  This is apparently causing
havoc with the multithreaded case -- as far as I can tell, some of my
threads get stranded using invalidated memory, and Badness happens from
there.

Am I reading this right?  Is this a real problem? ...or was it designed
that way?

Did you intend that vorbis_dsp_state instances can be shared between
threads?  Or are vorbis_dsp_state instances now just stateless, in that
one can encode vorbis_blocks on different vorbis_dsp_state instances and
still get continuous audio output? (I don't know how to put that any
differently; did that make sense?)

{+} Jeff Squyres
{+} squyres at cse.nd.edu
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to ND for 4 years and ended up staying for a decade"

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.