Thread: deadlock with shared_mutex on Windows

[Andrey <nikolay@…>]

Please see attached test. Code is very simple. It works when thread3 uses thread3_func_workaround function and test is deadlocked when thread3 uses thread3_func function. From the first view, it seems the problem in the shared_mutex::timed_lock function. Possible it have to signal "semaphores[unlock_sem]" semaphore when state.exclusive_waiting_blocked is changed from true to false. This action will wake up threads which are waiting for shared access.

P.S. I didn't try the same test using pthread, so it is a good idea to test (and fix if needed) pthread implementation as well.

[viboes]

Hi, since 1.50 there is the possibility to use a common implementation for shared_mutex defining BOOST_THREAD_PROVIDES_GENERIC_SHARED_MUTEX_ON_WIN or BOOST_THREAD_VERSION=3.

Please, could you tell me if this solves the issue?

See #4882.

[Andrey <nikolay@…>]

Defining BOOST_THREAD_PROVIDES_GENERIC_SHARED_MUTEX_ON_WIN solves the issue!!!

[viboes]

Reopened as BOOST_THREAD_PROVIDES_GENERIC_SHARED_MUTEX_ON_WIN will not be defined by default and as #7906 states there is a lost in performances when this define is defined.

[anonymous]

Replying to Andrey <nikolay@…>:

Please see attached test. Code is very simple. It works when thread3 uses thread3_func_workaround function and test is deadlocked when thread3 uses thread3_func function. From the first view, it seems the problem in the shared_mutex::timed_lock function. Possible it have to signal "semaphores[unlock_sem]" semaphore when state.exclusive_waiting_blocked is changed from true to false. This action will wake up threads which are waiting for shared access.

It seems your analysis were right. Please could you try the attached patch?

[viboes]

Committed revision [83525].