________________________________________ From: alsa-devel-bounces@alsa-project.org [alsa-devel-bounces@alsa-project.org] on behalf of Rémi Denis-Courmont [remi@remlab.net] Sent: Wednesday, November 14, 2012 3:03 PM To: alsa-devel@alsa-project.org Cc: Trent Piepho Subject: Re: [alsa-devel] Races in alsa-lib with threads
Hello,
Le mercredi 14 novembre 2012 21:49:36, Trent Piepho a écrit :
You claim that the Gstreamer ALSA sink plugin accesses alsa-lib from two threads simultaneously. Could you elaborate on how this can happen, maybe it is easy to fix?
gstreamer has no lock around the call to snd_pcm_delay(). So it can race with snd_pcm_wait() or snd_pcm_writei(), which are called in another thread. There is a lock around the block of code calling wait()/writei(), but this lock isn't used for calling delay().
Use non-blocking I/O and poll(). Then the snd_pcm_write() calls will not sleep and can be interlocked with snd_pcm_delay() calls.
It seems that they didn't know there would be a problem.
Eh? It is rather the exception for a library to be thread-safe when using the same object in multiple threads.
It looks more like "they" did not pay attention to what they were doing.
-- Rémi Denis-Courmont http://www.remlab.net/ _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
HI Rémi,
We are using non-blocking mode with snd_pcm_wait() and snd_pcm_writei(). We have a workable solution. Thanks for the advice.
Best Regards.
Rob