opus - May 2009 - Encoder crash in multithreading processing

Hi, I try to work with CELT encoder & decoder in 2 different threads at the
same time.
So I create/destroy encoder and encode in one thread and create/destroy
decoder and decode in other thread.
If I didn't protect celt_encoder_create, celt_encode_float and
celt_decoder_create, celt_decode_float with CRITICAL_SECTION
I get stable error in icwrs32 or ec_byte_write1 (more often) in encoder.

What does it mean ? Is CELT not thread-safe ? Any way to avoid this error
except CRITICAL_SECTION ?

Sergei

ps: I use last version from git repository, but I also checked with previous
version and with 2 compilers VC++ 2008 & Intel 11.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/opus/attachments/20090520/79c27a1c/attachment-0002.htm

Quoting Serguei Kouratov <ksubox at gmail.com>:
> Hi, I try to work with CELT encoder & decoder in 2 different threads at
the
> same time.
> So I create/destroy encoder and encode in one thread and create/destroy
> decoder and decode in other thread.
> If I didn't protect celt_encoder_create, celt_encode_float and
> celt_decoder_create, celt_decode_float with CRITICAL_SECTION
> I get stable error in icwrs32 or ec_byte_write1 (more often) in encoder.
>
> What does it mean ? Is CELT not thread-safe ? Any way to avoid this error
> except CRITICAL_SECTION ?
CELT is designed to be thread-safe in the context you're describing. While
there's a (tiny) chance that we have inadvertently defined a global
variable,
it's much more likely that there's a race in your code that causes CELT
to be
corrupted. That being said, if you manage to find any case where we really
aren't thread-safe, then we'd like to fix that. Also, just in case
there's
something wrong in the mode, can you try creating two mode objects (one the
encoder and one for the decoder) instead of one? It should work with one, this
is just to check that there's nothing wrong with the way the modes are being
shared by the encoder and decoder.

Cheers,

   Jean-Marc

Quoting Serguei Kouratov <ksubox at gmail.com>:

> ps: I use last version from git repository, but I also checked with
previous
> version and with 2 compilers VC++ 2008 & Intel 11.
Actually, that should also be the cause. Normally CELT uses C99 variable-size
arrays, but VC++ doesn't support them and fall back to a "global
stack" that we
allocate. Try defining USE_ALLOCA so the fallback becomes alloca(), which is
(hopefully) thread-safe.

   Jean-Marc