tree 3e69b7f43c06b14ca70fd87fd1b71253c6c966ee
parent 500d0a973d981f73e15eff49de78b5926dc19fc8
author Takashi Sakamoto <o-takashi@sakamocchi.jp> 1679678292 +0100
committer Alexander Martinz <amartinz@shiftphones.com> 1698213811 +0200
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEioN3RtFSeUXyJOKbzxW92aMhqbIFAmU4r7MACgkQzxW92aMh
 qbIwYQ//RdMIWquA1f0gCMNg/T61qzAXvSSCCD21M7hboGR4nln0jBFMNRccoy+N
 CDGb5J55qIIeKvqXMQFI5JgiDrMQMLpAFreF3P1NGjlo1IeLvap8QRtT5OM6j+hD
 1plJFLY+1H2IwzJP+kIAQ2CYBLIIyuJK54N+HraV1OOmg/zwExDILe9p/07DgUEU
 IddQ9tesDT3fpPxWwwIVddcrp07FTByWOlLsgZoSKhrpWD5sj+6z/hc3vLPqXmaJ
 hR8UUyrnEpnaS6HS82dNup9wP+gKZdSpJmDonXF/pbxhcvMIHOU1KMWCoD9pELyM
 QpgQ2tcECy6M1yohIWnh8Q/KF61dkX0IEsZWdrg+2pMuOobZ/2474pGDdoe1sffd
 OR7jHbqolEexCJ41ORDvcltAxKFhblJONwu6rDrzx9eu/w5vi1lxuBDXTiRszwJN
 chhr6CT3ZLAc+XXQjr1HKZVQlbAR6VRBVkqLRJIDsB4x2TL8D7hpzi1Hdzqjb4ug
 o5hoIPfDtOi8Ec8TR0ccZ7rO5XilWV5iyKKcihWo2BB3E5e1o4QQi/UgfopkLQlL
 oEDlyeul5W84CjaQzn/3r0tR343Hi3zz6Fyf97Ryf396DuTyhsddyfYairlv8KCZ
 OLIDEHtmTUA9s+6ayutNyeGaj+UbSmU5SS3fj773L/Bd3o4KkYw=
 =jWs7
 -----END PGP SIGNATURE-----

ALSA: control: use counting semaphore as write lock for ELEM_WRITE operation

In ALSA control interface, applications can execute two types of request
for value of members on each element; ELEM_READ and ELEM_WRITE. In ALSA
control core, these two requests are handled within read lock of a
counting semaphore, therefore several processes can run to execute these
two requests at the same time. This has an issue because ELEM_WRITE
requests have an effect to change state of the target element. Concurrent
access should be controlled for each of ELEM_READ/ELEM_WRITE case.

This commit uses the counting semaphore as write lock for ELEM_WRITE
requests, while use it as read lock for ELEM_READ requests. The state of
a target element is maintained exclusively between ELEM_WRITE/ELEM_READ
operations.

There's a concern. If the counting semaphore is acquired for read lock
in implementations of 'struct snd_kcontrol.put()' in each driver, this
commit shall cause dead lock. As of v4.13-rc5, 'snd-mixer-oss.ko',
'snd-emu10k1.ko' and 'snd-soc-sst-atom-hifi2-platform.ko' includes codes
for read locks, but these are not in a call graph from
'struct snd_kcontrol.put(). Therefore, this commit is safe.

In current implementation, the same solution is applied for the other
operations to element; e.g. ELEM_LOCK and ELEM_UNLOCK. There's another
discussion about an overhead to maintain concurrent access to an element
during operating the other elements on the same card instance, because the
lock primitive is originally implemented to maintain a list of elements on
the card instance. There's a substantial difference between
per-element-list lock and per-element lock.

Here, let me investigate another idea to add per-element lock to maintain
the concurrent accesses with inquiry/change requests to an element. It's
not so frequent for applications to operate members on elements, while
adding a new lock primitive to structure increases memory footprint for
all of element sets somehow. Experimentally, inquiry operation is more
frequent than change operation and usage of counting semaphore for the
inquiry operation brings no blocking to the other inquiry operations. Thus
the overhead is not so critical for usual applications. For the above
reasons, in this commit, the per-element lock is not introduced.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Alexander Grund <theflamefire89@gmail.com>
Signed-off-by: Ulrich Hecht <uli+cip@fpond.eu>
Change-Id: I2e14b47c0854ef14883a3e2c5628b3fa9f772a71