LIU Hao wrote:

>>  > 0023 has this:
>>  >
>>  >     assert(pthread_create(&thread, NULL, ThreadA, &mutex) == 0);
>>  >     Sleep(100);
>>  >     /**
>>  >      * Ensure we do not dead lock if thread did not lock mutex fast 
>> enough.
>>  >      */
>>  >     assert(pthread_mutex_trylock(&mutex) == EBUSY);
>>  >
>>  > I think this is a bit fragile; you can use a barrier here.
>>
>> Yeah, I had mixing feeling about this. Will it be ok to loop with 
>> `InterlockedExchange` in main until
>> thread sets a variable? I hesitate to use `pthread_barrier_t` because its 
>> implementation uses
>> `pthread_mutex_t`, so it would be a bit awkward.
>
> Right; probably you want a Windows event which will be set after the child 
> thread has acquired the mutex.

I really don't like dealing with code like this:

1. We will "signal" before second thread calls `pthread_mutex_lock` again, the 
one which deadlocks
2. Once "signaled", main thread calls `pthread_mutex_unlock` so that second 
thread can grab lock again and continue execution

It is possible, though unlikely, that main will unlock the mutex before second 
thread deadlocks by entering the wait state; that would result in a deadlock in 
main. I wrote code that accounts for it, that is no problem, although I don't 
like how unnecessary messier it gets.

I thought maybe it would be acceptable to simply return 77 (report test as 
skipped), instead of assert'ing, if call to `pthread_mutex_trylock` does not 
return EBUSY? I did not see original version to assert in either local testing 
or CI.

- Kirill Makurin

_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to