[vorbis-dev] Thread issues: clarification

[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).

None of the libvorbis/libvorbisfile functions are safely reentrant for
a given single instance of a data structure.  Even the functions that
just look like they read data are modifying state.  

> 
> _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?

It's designed that way.  With my obligations to beta 4 mostly handled,
I'll be spending time this week on docs.  Actually, you're just about
qualified at this point to do it too :-)

> 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?)

vorbis_blocks are standalone but not stateless (you may have several
pointing to one vorbis_dsp_state and each one in parallel with the
others so long as the vorbis_dsp_state is still valid; the reference
to the vorbis_dsp_state is actually readonly).  vorbis_dsp_state
structs are definately not stateless.  Every call that takes a
vorbis_dsp_state, even ones that look trivial, may change the state.

Monty

--- >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.