Wondering about locking model in ResamplingAudioSource

[rebbur]

@dinaiz

The difference between a re-entrant and a non re-entrant lock is that in the former case, the same thread can aquire the lock multiple times, while in the later case, that situation would create a deadlock.

Ok thanx, so don’t use it if there is a chance that the same thread will acquire the lock more than once, but isn’t that just the case with ResamplingAudioSource when the ratio is updated in realtime?

[dinaiz]

@gekkie100

Ok thanx, so don’t use it if there is a chance that the same thread will acquire the lock more than once, but isn’t that just the case with ResamplingAudioSource when the ratio is updated in realtime?

Well, in my mind, that is not possible : if a thread starts changing the ratio, this thread will be locked by the SpinLock. During that time, how could it change the ratio again ? (I’m no multithread specialist, and I might be wrong, but in the end, it seems to work, doesn’t it ? )

[dinaiz]

@gekkie100

Ok thanx, so don’t use it if there is a chance that the same thread will acquire the lock more than once, but isn’t that just the case with ResamplingAudioSource when the ratio is updated in realtime?

Well, in my mind, that is not possible : if a thread starts changing the ratio, this thread will be locked by the SpinLock. During that time, how could it change the ratio again ? (I’m no multithread specialist, and I might be wrong, but in the end, it seems to work, doesn’t it ? )

[TheVinn]

ResamplingAudioSource should make synchronization the responsibility of the caller. Or at least, it should be a template parameter (so we can do away with the locking).

[dinaiz]

@TheVinn

ResamplingAudioSource should make synchronization the responsibility of the caller. Or at least, it should be a template parameter (so we can do away with the locking).

Yeah why not pass the critical section as a template parameter, like in Arrays ?