[FFmpeg-devel] [PATCH] lavc/utils: remove unnecessary locking
wm4
nfxjfg at googlemail.com
Tue Dec 12 10:04:04 EET 2017
On Tue, 12 Dec 2017 08:50:01 +0100
Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> On Tue, Dec 12, 2017 at 12:25 AM, Aaron Levinson
> <alevinsn_dev at levland.net> wrote:
> > On 12/8/2017 2:27 AM, Michael Niedermayer wrote:
> >>
> >> On Fri, Dec 08, 2017 at 09:49:25AM +0100, Hendrik Leppkes wrote:
> >>>
> >>> On Fri, Dec 8, 2017 at 6:09 AM, Rostislav Pehlivanov
> >>> <atomnuker at gmail.com> wrote:
> >>>>
> >>>> Its already done by lockmgr.
> >>>>
> >>>> Signed-off-by: Rostislav Pehlivanov <atomnuker at gmail.com>
> >>>> ---
> >>>> libavcodec/utils.c | 6 ------
> >>>> 1 file changed, 6 deletions(-)
> >>>>
> >>>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> >>>> index baf09119fe..796d24dcbb 100644
> >>>> --- a/libavcodec/utils.c
> >>>> +++ b/libavcodec/utils.c
> >>>> @@ -115,7 +115,6 @@ static int (*lockmgr_cb)(void **mutex, enum AVLockOp
> >>>> op) = NULL;
> >>>> #endif
> >>>>
> >>>>
> >>>> -static atomic_bool ff_avcodec_locked;
> >>>> static atomic_int entangled_thread_counter = ATOMIC_VAR_INIT(0);
> >>>> static void *codec_mutex;
> >>>> static void *avformat_mutex;
> >>>> @@ -1943,7 +1942,6 @@ int av_lockmgr_register(int (*cb)(void **mutex,
> >>>> enum AVLockOp op))
> >>>>
> >>>> int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
> >>>> {
> >>>> - _Bool exp = 0;
> >>>> if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
> >>>> !codec->init)
> >>>> return 0;
> >>>>
> >>>> @@ -1959,21 +1957,17 @@ int ff_lock_avcodec(AVCodecContext *log_ctx,
> >>>> const AVCodec *codec)
> >>>> atomic_load(&entangled_thread_counter));
> >>>> if (!lockmgr_cb)
> >>>> av_log(log_ctx, AV_LOG_ERROR, "No lock manager is set,
> >>>> please see av_lockmgr_register()\n");
> >>>> - atomic_store(&ff_avcodec_locked, 1);
> >>>> ff_unlock_avcodec(codec);
> >>>> return AVERROR(EINVAL);
> >>>> }
> >>>> - av_assert0(atomic_compare_exchange_strong(&ff_avcodec_locked, &exp,
> >>>> 1));
> >>>> return 0;
> >>>> }
> >>>>
> >>>> int ff_unlock_avcodec(const AVCodec *codec)
> >>>> {
> >>>> - _Bool exp = 1;
> >>>> if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
> >>>> !codec->init)
> >>>> return 0;
> >>>>
> >>>> - av_assert0(atomic_compare_exchange_strong(&ff_avcodec_locked, &exp,
> >>>> 0));
> >>>> atomic_fetch_add(&entangled_thread_counter, -1);
> >>>> if (lockmgr_cb) {
> >>>> if ((*lockmgr_cb)(&codec_mutex, AV_LOCK_RELEASE))
> >>>> --
> >>>> 2.15.1.424.g9478a66081
> >>>>
> >>>
> >>> These variables never performed any locking, they only existed as a
> >>> sanity check that lock/unlock is always called in pairs. If that is
> >>> really required is up for discussion.
> >>
> >>
> >> They shuld be usefull to detect some bugs related to locking
> >>
> >> [...]
> >
> >
> > I don't have the most recent response to this e-mail, from Hendrik, in my
> > inbox anymore, but I spent some time reviewing the patch, and I also don't
> > see any point to making access to ff_avcodec_locked atomic.
> >
> > Prior to patch
> > https://github.com/FFmpeg/FFmpeg/commit/590136e78da3d091ea99ab5432543d47a559a461
> > , ff_avcodec_locked was declared as volatile and also specified as an extern
> > in internal.h. Neither the volatile declaration nor the global exposure of
> > ff_avcodec_locked are necessary. The patch eliminated the global exposure,
> > but it replaced "volatile" with "atomic".
> >
> > Write access to ff_avcodec_locked is already protected via lockmgr_cb. If,
> > somehow, lockmgr_cb is NULL, which shouldn't happen in practice, the
> > entangled_thread_counter backup approach that immediately follows isn't
> > sufficient as currently implemented to protect writes to ff_avcodec_locked,
> > which makes me wonder why it is there in the first place. It is possible to
> > use entangled_thread_counter in a way that protects access to
> > ff_avcodec_locked though, and I think that's the intention of the code.
> >
> > I think the correct approach is to mostly restore the code prior to patch
> > https://github.com/FFmpeg/FFmpeg/commit/590136e78da3d091ea99ab5432543d47a559a461
> > but to leave ff_avcodec_locked statically declared and eliminate the
> > volatile designation.
>
> I've reverted the commit last night already.
>
> >
> > On a separate note, this whole approach of using
> > ff_lock_avcodec/ff_unlock_avcodec seems a little hokey to me. It is
> > effectively using a global lock (via lockmgr_cb) to control access to avctx,
> > which should be local to the calling thread. As implemented, it prevents
> > two concurrent calls to avcodec_open2() from proceeding simultaneously. As
> > far as I can tell, the implementation of avcodec_open2() doesn't modify any
> > global structures and only modifies avctx. I would think that a better
> > approach would be to use a lock that is specific to the avctx object,
> > perhaps one stored in avctx->internal. This approach would also eliminate
> > the codec_mutex memory leak.
> >
>
> The Lock doesn't lock access to avctx, it locks access to the AVCodec
> - specifically when opening it. The reason for that is that many
> codecs still have global data which they initialize on opening, so
> opening a codec is locked.
> We've been working on and off to remove any global codec state and
> replacing it with either hardcoded static data or context-state, or
> using pthread_once, and any codec that is known to not do any unsafe
> global init is flagged with FF_CODEC_CAP_INIT_THREADSAFE, and the
> locking is skipped.
>
> AVCodecs are const, so they can't contain a mutex (and sometimes data
> is also stored between multiple codecs), and multiple avctx can refer
> to the same AVCodec, so there is no place to store a mutex but
> globally. We would all be happy to get rid of the lock manager, but
> it isn't quite as simple. Lots of work still remains to check and fix
> all codecs.
Incorrect. AVCodecs are mutable, because otherwise you couldn't make
them part of the codec linked list.
More information about the ffmpeg-devel
mailing list