[alsa-devel] locking looks odd

[Samuel Thibault]

Hello,

We are having odd issues with libasound 1.1.2 which we didn't have with
libasound 1.1.1, more precisely

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833950

so I'm having a look at the locking API introduced in 1.1.2, and there
are some oddities:

- snd_pcm_new seems to initialize pcm->thread_safe to 0 by default, this
  does not seem safe. The attached patch initializes it to 1, which
  fixes the bug in our tests.

- snd_pcm_hw_open_fd forces it to 1, thus ignoring what snd_pcm_new set.

- one can find both __snd_pcm_lock and snd_pcm_lock functions, what is
  the expected difference between them?

- __snd_pcm_lock takes locks when thread_safe >= 0, while snd_pcm_lock
  takes locks when thread_safe == 0, this looks really odd.

- libasound could just not link against libpthread,
  pthread_mutex_lock/unlock are already provided as empty stubs by libc,
  the overhead will thus only be hit when the application links against
  libpthread (libasound will then properly use pthread locks).

Samuel
-------------- next part --------------
--- ./src/pcm/pcm.c.orig	2016-08-10 19:39:59.881564371 +0200
+++ ./src/pcm/pcm.c	2016-08-10 19:40:04.211539997 +0200
@@ -2544,6 +2544,7 @@
 	pcm->fast_op_arg = pcm;
 	INIT_LIST_HEAD(&pcm->async_handlers);
 #ifdef THREAD_SAFE_API
+	pcm->thread_safe = 1;
 	pthread_mutex_init(&pcm->lock, NULL);
 	{
 		static int default_thread_safe = -1;