Hi,
I removed the ff_thread_report_progress and ff_thread_await_progress
changes from this patch. This patch now only changes
libavutil/atomic*. I also added some comments to libavutil/atomic.h to
describe how the acquire and release operations are intended to be
used.
While working on the comments in libavutil/atomic.h, I noticed that
the comment for avpriv_atomic_int_add_and_fetch contradicts the code.
The comment says:
* @note This does NOT act as a memory barrier. This is primarily
* intended for reference counting.
But the primary implementation in libavutil/atomic_gcc.h uses the
sequentially consistent ordering rather than the relaxed ordering:
#define avpriv_atomic_int_add_and_fetch atomic_int_add_and_fetch_gcc
static inline int atomic_int_add_and_fetch_gcc(volatile int *ptr, int inc)
{
#if HAVE_ATOMIC_COMPARE_EXCHANGE
return __atomic_add_fetch(ptr, inc, __ATOMIC_SEQ_CST);
#else
return __sync_add_and_fetch(ptr, inc);
#endif
}
How should we make the comment match the code? I suggest that the
default memory order of avpriv_atomic_int_add_and_fetch be the
sequentially consistent ordering, and add a
avpriv_atomic_int_add_and_fetch_relaxed function that does not issue a
memory barrier.
If you agree with my proposal, I can write a separate patch to do that.
Wan-Teh Chang
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
