[vlc-devel] [PATCH 2/7] win32/inhibit: signal while holding the lock

[Steve Lhomme]

Personally I don't understand why the runtime would reorder 
multithreading calls.

But it seems more logical to do the unlock after the signal. Either it 
worked by accident or supposedly because the runtime would reorder calls 
? More info would be welcome.

On 2020-02-04 10:11, Thomas Guillem wrote:
> Indeed, OK for 2 and 3.
> 
> On Mon, Feb 3, 2020, at 22:13, Rémi Denis-Courmont wrote:
>> This is the 21st century. The C run-time threading subsystem knows better
>> than you how to optimise condition variables.
>> ---
>>   modules/video_output/win32/inhibit.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/modules/video_output/win32/inhibit.c
>> b/modules/video_output/win32/inhibit.c
>> index d23dcc33e4..566b311189 100644
>> --- a/modules/video_output/win32/inhibit.c
>> +++ b/modules/video_output/win32/inhibit.c
>> @@ -42,8 +42,8 @@ static void Inhibit (vlc_inhibit_t *ih, unsigned mask)
>>       vlc_inhibit_sys_t *sys = ih->p_sys;
>>       vlc_mutex_lock(&sys->mutex);
>>       sys->mask = mask;
>> -    vlc_mutex_unlock(&sys->mutex);
>>       vlc_cond_signal(&sys->cond);
>> +    vlc_mutex_unlock(&sys->mutex);
>>   }
>>   
>>   static void RestoreStateOnCancel( void* p_opaque )
>> -- 
>> 2.25.0
>>
>> _______________________________________________
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> https://mailman.videolan.org/listinfo/vlc-devel
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
>