Why doesn't mixer control (values) have some kind of locking mechanism? (mutex?)

[Jaroslav Kysela]

Dne 06. 08. 20 v 16:47 Takashi Sakamoto napsal(a):
> Hi,
> 
> On Thu, Aug 06, 2020 at 08:31:51PM +0800, Tom Yan wrote:
>> Yeah I suppose a "full" lock would do. (That was what I was trying to
>> point out. I don't really understand Pierre's message. I merely
>> suppose you need some facility in the kernel anyway so that you can
>> lock from userspace.) I hope that amixer the utility will at least have
>> the capability to reschedule/wait by then though (instead of just
>> "failing" like in your python demo).
> 
> As long as I know, neither tools in alsa-utils/alsa-tools nor pulseaudio
> use the lock mechanism. In short, you are the first person to address
> to the issue. Thanks for your patience since the first post in 2015.
> 
>> As for the compare-and-swap part, it's just a plus. Not that
>> "double-looping" for *each* channel doesn't work. It just again seems
>> silly and primitive (and was once confusing to me).
> 
> I prepare a rough kernel patch abount the compare-and-swap idea for
> our discussion. The compare-and-swap is done under lock acquisition of
> 'struct snd_card.controls_rwsem', therefore many types of operations
> to control element (e.g. read as well) get affects. This idea works
> well at first when alsa-lib supports corresponding API and userspace
> applications uses it. Therefore we need more work than changing just
> in userspace.
> 
> But in my opinion, if things can be solved just in userspace, it should
> be done with no change in kernel space.

The compare-and-swap is just a limited mechanism which does not resolve all
possible usage cases (mainly the operation grouping).

I read the whole story and I basically don't think that we need to handle this
in the kernel space. The arbitration should be easily implementable in the
user space. We can agree that we need to add a new extension which will grant
to the user space application the exclusive access to change one or more
control elements exclusively possibly based on the previous contents.

I would propose a new alsa-lib API extension (which may be shared with other
ALSA user space APIs): System V semaphore (man 2 semop). We can use the named
semaphore. Two functions can be added like snd_ctl_transaction_begin() and
snd_ctl_transaction_end() to alsa-lib. The wait condition can be handled
through an argument to snd_ctl_transaction_begin(). It might be probably also
nice to consider the poll multiplexing implementation for the wait condition
(use a message queue to notify other tasks when the semaphore was released).

					Jaroslav

-- 
Jaroslav Kysela <perex at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.