On Sat, 20 Jan 2018 12:52:46 +0700
Muhammad Faiz <mfc...@gmail.com> wrote:
> On Sat, Jan 20, 2018 at 11:49 AM, James Almer <jamr...@gmail.com> wrote:
> > On 1/20/2018 1:29 AM, Muhammad Faiz wrote:
> >> Help avoiding malloc-free cycles when allocating-freeing common
> >> structures.
> >>
> >> Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
> >> ---
> >> libavutil/staticpool.h | 117
> >> +++++++++++++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 117 insertions(+)
> >> create mode 100644 libavutil/staticpool.h
> >>
> >> diff --git a/libavutil/staticpool.h b/libavutil/staticpool.h
> >> new file mode 100644
> >> index 0000000000..9c9b2784bc
> >> --- /dev/null
> >> +++ b/libavutil/staticpool.h
> >> @@ -0,0 +1,117 @@
> >> +/*
> >> + * This file is part of FFmpeg.
> >> + *
> >> + * FFmpeg is free software; you can redistribute it and/or
> >> + * modify it under the terms of the GNU Lesser General Public
> >> + * License as published by the Free Software Foundation; either
> >> + * version 2.1 of the License, or (at your option) any later version.
> >> + *
> >> + * FFmpeg is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> >> + * Lesser General Public License for more details.
> >> + *
> >> + * You should have received a copy of the GNU Lesser General Public
> >> + * License along with FFmpeg; if not, write to the Free Software
> >> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> >> 02110-1301 USA
> >> + */
> >> +
> >> +#ifndef AVUTIL_STATICPOOL_H
> >> +#define AVUTIL_STATICPOOL_H
> >> +
> >> +#include <stdatomic.h>
> >> +#include "avassert.h"
> >> +#include "mem.h"
> >> +
> >> +/**
> >> + * FF_STATICPOOL allocate memory without av_malloc if possible
> >> + * @param size must be 2^n between 64 and 4096
> >> + */
> >> +#define FF_STATICPOOL_DECLARE(type, size)
> >> \
> >> +typedef struct type##_StaticPoolWrapper {
> >> \
> >> + type buf;
> >> \
> >> + unsigned index;
> >> \
> >> + atomic_uint next;
> >> \
> >> +} type##_StaticPoolWrapper;
> >> \
> >> +
> >> \
> >> +static atomic_uint type##_staticpool_next;
> >> \
> >> +static atomic_uint type##_staticpool_last;
> >> \
> >> +static type##_StaticPoolWrapper type##_staticpool_table[size];
> >> \
> >> +
> >> \
> >> +static type *type##_staticpool_malloc(void)
> >> \
> >> +{
> >> \
> >> + unsigned val, index, serial, new_val;
> >> \
> >> +
> >> \
> >> + av_assert0((size) >= 64 && (size) <= 4096 && !((size) & ((size) -
> >> 1))); \
> >> +
> >> \
> >> + /* use serial, avoid spinlock */
> >> \
> >> + /* acquire, so we don't get stalled table[index].next */
> >> \
> >> + val = atomic_load_explicit(&type##_staticpool_next,
> >> memory_order_acquire); \
> >> + do {
> >> \
> >> + index = val & ((size) - 1);
> >> \
> >> + serial = val & ~((size) - 1);
> >> \
> >> + new_val =
> >> atomic_load_explicit(&type##_staticpool_table[index].next,
> >> memory_order_relaxed) | (serial + (size)); \
> >> + } while
> >> (!atomic_compare_exchange_strong_explicit(&type##_staticpool_next, &val,
> >> new_val, \
> >
> > The wrappers for atomic_compare_exchange_* in the compat folder are not
> > really working and fixing them is supposedly not trivial, so this will
> > only work with GCC and Clang but not with for example MSVC or SunCC.
>
> What's the problem? I only see that stdatomic compat make typedef
> every atomic type to intptr_t, so atomic_*64_t won't work if
> sizeof(intptr_t) == 32.
> Here I use atomic_uint, so I guess it will work.
>
> Note that if atomic_compare_exchange_* is broken then atomic_fetch_*
> will also be broken because atomic_fetch_* call
> atomic_compare_exchange_* on suncc compat.
>
> >
> > Can you implement this using mutexes instead, or otherwise avoid using
> > atomic_compare_exchange_*? You can even use static mutex initialization
> > now for all targets, and not just native pthreads.
>
> Using mutex makes implementation slower.
> Using atomic_exchange requires spin lock.
Uncontended mutexes are spinlocks.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
