Hi Takashi,
All our test cases are working fine again with your commit [1]. Thanks a lot.
I think all commits which introducing unlocked versions of the API functions can be reverted e.g [2]. Or what do you think?
[1] http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=1cb217ead9aff029f1942... [2] http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=24e63b75275e9c923...
Best regards
Timo Wischer Software Group I (ADITG/SW1)
Tel. +49 5121 49 6938
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Freitag, 21. April 2017 20:44 To: Wischer, Timo (ADITG/SW1) Cc: alsa-devel@alsa-project.org Subject: Re: [alsa-devel] FW: Further goals of thread-safe PCM API
On Thu, 20 Apr 2017 17:42:06 +0200, Takashi Iwai wrote:
On Thu, 20 Apr 2017 16:01:47 +0200, Wischer, Timo (ADITG/SW1) wrote:
Hi everyone,
I am wondering about the implementation of the new thread-safety feature [1]. There are so many issues with deadlocks (e.g. [3]) which were already solved but also which are not yet solved.
Why do you not using a recursive mutex to avoid most of this deadlocks? Using PTHREAD_MUTEX_RECURSIVE as the pthread attribute [2].
It sounds like a good idea. Although the plugin should be written not to cause deadlock, it's better to avoid such a pain by allowing the recursive lock.
Care to test and submit the proper patch?
Never mind, I committed a quick fix to git repo now. Thanks for the suggestion!
Takashi