[alsa-devel] FW: Further goals of thread-safe PCM API

Wischer, Timo (ADITG/SW1) twischer at de.adit-jv.com
Thu Apr 27 10:45:55 CEST 2017


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=1cb217ead9aff029f194208bf484be1ba956b194
[2] http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=24e63b75275e9c923c336b8dba3919b980e8f234

Best regards

Timo Wischer
Software Group I (ADITG/SW1)

Tel. +49 5121 49 6938

-----Original Message-----
From: Takashi Iwai [mailto:tiwai at suse.de] 
Sent: Freitag, 21. April 2017 20:44
To: Wischer, Timo (ADITG/SW1)
Cc: alsa-devel at 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


More information about the Alsa-devel mailing list