On 06.02.23 21:11, Patrick Lerda wrote:
On 03/02/2023 10:36, Klaus Schmidinger wrote:
On 02.02.23 23:47, patrick9...@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
_______________________________________________
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
