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