Re: [PATCH 24/44] fireworks: Add MIDI interface

[Clemens Ladisch <clemens@ladisch.de>]

Takashi Sakamoto wrote:
> (Apr 4 2014 06:20), Clemens Ladisch wrote:
>>> +++ b/sound/firewire/fireworks/fireworks_midi.c
>>> +static int midi_capture_open(struct snd_rawmidi_substream *substream)
>>> +{
>>> +    struct snd_efw *efw = substream->rmidi->private_data;
>>> +
>>> +    efw->capture_substreams++;
>>
>> The MIDI .open callback is not synchronized with the PCM callbacks;
>> this might race and must be protected with a mutex.
>
> Exactly. And I've realized it.
>
> The race appears between some processes to handle substream counter at
> the same time. The counter is changed by below operations:
>  PCM  .hw_param/.hw_free
>  MIDI .open/.close
>
> Well, for this issue, I think it better to use atomic_t for substream
> counter than mutex. The way to use mutex is propper for MIDI .open/
> .close because these functions also execure stream_start_duplex() /
> stream_stop_duplex() (then I must move mutex_lock/mutex_unlock from
> stream.c). But PCM .hw_param/.hw_free just increment / decrement
> substream counter. I think it consts expensive than such simple
> operation.

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.)


Regards,
Clemens