On 06.02.23 21:11, Patrick Lerda wrote:
On 03/02/2023 10:36, Klaus Schmidinger wrote:
On 02.02.23 23:47, patrick9876@free.fr wrote:
On 02/02/2023 23:27, Klaus Schmidinger wrote:
On 02.02.23 23:16, Patrick Lerda wrote:
Beside preventing crashes with vdr-2.6.3 this is required to get vdr to work properly with the gcc thread sanitizer.
cRingBufferLinear was designed to be thread safe without locking. What "crashes with vdr-2.6.3" are you referring to?
Klaus
With a -fsanitize=thread compiled version of vdr, I had some crashes that happened quickly, for instance: ...
Before making such deep changes to code that has been running flawlessly for years (or even decades) I need to be convinced that this is absolutely necessary.
Is there a problem that occurs if you run VDR *without* -fsanitize=thread?
Klaus
I had in the past a crash from time to time, with vdr-2.6.3 this seems to be worse. Anyway, I was checking with vdr-2.4.7 and the problem is the same. This class is shared by at least 2 threads
It is supposed to be shared by *exactly* two threads. One only writing 'head', the other only writing 'tail'. The concept was taken from the original DVB driver, which also implemented the ring buffer without locking.
with more than one shared object; this means that without a mutex, the behavior is undefined from a C++ perspective. With -fsanitize=thread the compiler could add some jitter and that seems to trigger quickly a crash. You should check in your environment with -fsanitize=thread, this is fastest way to check for thread safety.
If there really were such a big problem, I would expect it would happen a lot more often. However, this is the first time I hear of a problem that might stem from the implmentation of the ring buffer. What exactly is it that you're doing that causes this? Does it also happen if you don't do that?
Klaus