Re: [FFmpeg-devel] [PATCH] Stop using _explicit atomic operations where not necessary.

2021-06-12 Thread Andreas Rheinhardt
Anton Khirnov: > Quoting Andreas Rheinhardt (2021-06-06 19:20:38) >> Anton Khirnov: >>> Quoting Andreas Rheinhardt (2021-06-06 11:13:00) Anton Khirnov: > Memory ordering constraints other than the default (sequentially > consistent) can behave in very unintuitive and unexpected ways, a

Re: [FFmpeg-devel] [PATCH] Stop using _explicit atomic operations where not necessary.

2021-06-10 Thread Anton Khirnov
Quoting Andreas Rheinhardt (2021-06-06 19:20:38) > Anton Khirnov: > > Quoting Andreas Rheinhardt (2021-06-06 11:13:00) > >> Anton Khirnov: > >>> Memory ordering constraints other than the default (sequentially > >>> consistent) can behave in very unintuitive and unexpected ways, and so > >>> should

Re: [FFmpeg-devel] [PATCH] Stop using _explicit atomic operations where not necessary.

2021-06-06 Thread Andreas Rheinhardt
Anton Khirnov: > Quoting Andreas Rheinhardt (2021-06-06 11:13:00) >> Anton Khirnov: >>> Memory ordering constraints other than the default (sequentially >>> consistent) can behave in very unintuitive and unexpected ways, and so >>> should be avoided unless there is a strong (typically performance)

Re: [FFmpeg-devel] [PATCH] Stop using _explicit atomic operations where not necessary.

2021-06-06 Thread Anton Khirnov
Quoting Andreas Rheinhardt (2021-06-06 11:13:00) > Anton Khirnov: > > Memory ordering constraints other than the default (sequentially > > consistent) can behave in very unintuitive and unexpected ways, and so > > should be avoided unless there is a strong (typically performance) > > reason for usi

Re: [FFmpeg-devel] [PATCH] Stop using _explicit atomic operations where not necessary.

2021-06-06 Thread James Almer
On 6/6/2021 8:39 AM, Andreas Rheinhardt wrote: James Almer: On 6/5/2021 11:27 AM, Anton Khirnov wrote: Memory ordering constraints other than the default (sequentially consistent) can behave in very unintuitive and unexpected ways, and so should be avoided unless there is a strong (typically pe

Re: [FFmpeg-devel] [PATCH] Stop using _explicit atomic operations where not necessary.

2021-06-06 Thread Andreas Rheinhardt
James Almer: > On 6/5/2021 11:27 AM, Anton Khirnov wrote: >> Memory ordering constraints other than the default (sequentially >> consistent) can behave in very unintuitive and unexpected ways, and so >> should be avoided unless there is a strong (typically performance) >> reason for using them. Thi

Re: [FFmpeg-devel] [PATCH] Stop using _explicit atomic operations where not necessary.

2021-06-06 Thread Andreas Rheinhardt
Anton Khirnov: > Memory ordering constraints other than the default (sequentially > consistent) can behave in very unintuitive and unexpected ways, and so > should be avoided unless there is a strong (typically performance) > reason for using them. This holds especially for memory_order_relaxed, >

Re: [FFmpeg-devel] [PATCH] Stop using _explicit atomic operations where not necessary.

2021-06-05 Thread Anton Khirnov
Quoting James Almer (2021-06-05 16:46:01) > On 6/5/2021 11:27 AM, Anton Khirnov wrote: > > Memory ordering constraints other than the default (sequentially > > consistent) can behave in very unintuitive and unexpected ways, and so > > should be avoided unless there is a strong (typically performanc

Re: [FFmpeg-devel] [PATCH] Stop using _explicit atomic operations where not necessary.

2021-06-05 Thread James Almer
On 6/5/2021 11:27 AM, Anton Khirnov wrote: Memory ordering constraints other than the default (sequentially consistent) can behave in very unintuitive and unexpected ways, and so should be avoided unless there is a strong (typically performance) reason for using them. This holds especially for me

[FFmpeg-devel] [PATCH] Stop using _explicit atomic operations where not necessary.

2021-06-05 Thread Anton Khirnov
Memory ordering constraints other than the default (sequentially consistent) can behave in very unintuitive and unexpected ways, and so should be avoided unless there is a strong (typically performance) reason for using them. This holds especially for memory_order_relaxed, which imposes no ordering