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

Anton Khirnov anton at khirnov.net
Sat Jun 5 19:49:05 EEST 2021


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 performance)
> > reason for using them. This holds especially for memory_order_relaxed,
> > which imposes no ordering constraints.
> 
> Performance is important for FIFO, though. Could they use a laxer order 
> at least for the fetch_sub and fetch_add cases?

Given that it uses AVThreadMessageQueue to send packets to the consumer
thread, and operations on AVThreadMessageQueue involve a full mutex
lock+unlock, I really doubt that atomic operations would be the
bottleneck here.

> 
> Also, commit fed50c4304e, which made cpu_flags an atomic type, states 
> that ThreadSanitizer stopped reporting races on tests/cpu_init after 
> that change, so maybe memory order is not important for it, only atomicity.
> In any case these cpu and mem functions are hardly a bottleneck 
> anywhere, and rarely called outside of debugging, so this change is ok.

AFAIU tsan will only find actual races. With atomisc you will not get
races, but the results might not be what you expect.

-- 
Anton Khirnov


More information about the ffmpeg-devel mailing list