Hi Clemens,
(Apr 6 2014 23:52), Clemens Ladisch wrote:
> The fast path of mutex_(un)lock already is quite heavily optimized.
> Optimizations should not be added unless they are actually needed; in
> this case, the difference would not be noticeable, especially because
> none of these functions are called frequently. (But if the code using
> atomic_t ends up being simpler, there's no reason not to use it.)
OK. I should not have mentioned about optimization.
My intent to add stream.c is to make it simple for PCM/MIDI
functionalities to handle streams.
When needing to start streams, PCM/MIDI functionalities increment
reference counter and call stream_start_duplex(). Then needed streams
are started.
When needing to stop streams, PCM/MIDI functionalities decrement
reference counter and call stream_stop_duplex(). Then needless streams
are stopped.
In both cases, function call following to changing reference counter.
But for PCM functionality, these must be separated because of .prepare()
call at XRUN. When XRUN occurs, application may call snd_pcm_prepare().
Then reference counter should not be incremented.
I use this way for fireworks/bebob drivers. So I hope to keep the codes
simple and safe to avoid large mistakes.
In this reason, I prefer to use mutex for function itself and atomic_t
for reference counter. If both of them must protected with mutex, it
brings more codes for PCM/MIDI functionalities. I want to avoid this.
Thanks
Takashi Sakamoto
o-takashi at sakamocchi.jp