Thread Safety in x265_set_globals

[Simon Descarries]

We're using using X265 in a multi threaded application and just recently caught some crashes on initialization that point towards x265_set_globals. We found there was a race condition where one thread would initialize the tables while another accesses them.

We'd like to propose a patch for this, but aside from the crash we'd also like the possibility of using different max CU sizes in the same process. Is there a reason for the current limitation? Could we simply initialize tables for all CU sizes and point to the proper one as needed?

[Simon Descarries]

Proposed minimum patch to address the thread safety issue.

[Simon Descarries]

No failure workaround - override parameters with static min max CU size to allow encoding.

[Deepthi Nandakumar]

Ok, I think what you're looking for here is a ScopedLock. If you could send the patch to the ML, that would be the best place for a detailed review. A signed CLA would also be good.

The global tables and variables like g_maxCUSize etc are the reason behind this limitation. Yes, creating indexed tables for 3 possible CTU sizes and removing all accesses to the global variables will solve it - but it's a fair amount of work - so, just not priority at the moment.

[Deepthi Nandakumar]

param: prevent race conditions in initialising global tables (refs #247)

Reset param if different encoder instances have different CU sizes.

→ <<cset f60818c73f3b>>

[Simon Descarries]

Thanks! That will work fine for now.

[Simon Descarries]

Confirmed fixed with cset f60818c73f3b; cannot reproduce a crash and encoding functions as expected. This issue can be closed.