[x264-devel] Fix clobbering of mutex/cvs

[Jason Garrett-Glaser]

On Mon, Mar 12, 2012 at 5:15 PM, pps . <mtlroom at hotmail.com> wrote:
> I downloaded x264 git a couple of days ago and I tried to use it on windows.
> It was always crashing if I used win-threads and backtrace was corrupted, I
> wasn't even able to see what caused it. Apparently, it crashed when calling
> some win-api.
> Today I pulled the new fix (by Anton Mitrofanov,
> Commit:5c85e0a2b7992fcaab09418e3fcefc613cffc743) and the problem is gone.
>
> When I tried to look into it, I saw some strange code:
>
> int x264_pthread_mutex_lock( x264_pthread_mutex_t *mutex )
> {
>     static x264_pthread_mutex_t init = X264_PTHREAD_MUTEX_INITIALIZER;
>     if( !memcmp( mutex, &init, sizeof(x264_pthread_mutex_t) ) )
>         *mutex = thread_control.static_mutex;
>     EnterCriticalSection( mutex );
>     return 0;
> }
>
> As I understand, if some mutex wasn't initialized, it will be overwritten
> with the thread_control.static_mutex. How is that might make sense? Does
> that match regular pthread behavior?

Regular pthreads have PTHREAD_MUTEX_INITIALIZER, which allows
initialization of static mutexes, so yes.

> Is that sure that windows'
> CRITICAL_SECTION can be reused in that way? Internally it contains some
> opaque pointers/handlers CRITICAL_SECTION.hCrit or handlers to semaphores
> etc. It all depends on the OS version. In any case, the bible says that "A
> critical section object cannot be moved or copied":

Admittedly, the only code that uses that is a single mutex which isn't
really necessary on any Windows-supported architecture anyways.

Jason