[FFmpeg-devel] [PATCH 1/3] avutil/get_pool: Remove redundant initial atomic operation
Hendrik Leppkes
h.leppkes at gmail.com
Sun Mar 17 19:16:56 CET 2013
On Sun, Mar 17, 2013 at 7:06 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Sun, Mar 17, 2013 at 06:54:35PM +0100, Hendrik Leppkes wrote:
>> On Sun, Mar 17, 2013 at 6:46 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > 602->442 dezicycles
>> >
>> > Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
>> > ---
>> > libavutil/buffer.c | 6 +++---
>> > 1 file changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/libavutil/buffer.c b/libavutil/buffer.c
>> > index d268a7f..3475e57 100644
>> > --- a/libavutil/buffer.c
>> > +++ b/libavutil/buffer.c
>> > @@ -239,14 +239,14 @@ void av_buffer_pool_uninit(AVBufferPool **ppool)
>> > /* remove the whole buffer list from the pool and return it */
>> > static BufferPoolEntry *get_pool(AVBufferPool *pool)
>> > {
>> > - BufferPoolEntry *cur = NULL, *last = NULL;
>> > + BufferPoolEntry *cur = *(void * volatile *)&pool->pool, *last = NULL;
>> >
>> > - do {
>> > + while (cur != last) {
>> > FFSWAP(BufferPoolEntry*, cur, last);
>> > cur = avpriv_atomic_ptr_cas((void * volatile *)&pool->pool, last, NULL);
>> > if (!cur)
>> > return NULL;
>> > - } while (cur != last);
>> > + }
>> >
>> > return cur;
>> > }
>> > --
>> > 1.7.9.5
>> >
>>
>>
>> I don't think you can safely assume that the initial get is atomic
>> because there is no memory barrier, and considering this function is
>> called only a handful of times per frame, i would stay on the safe
>> side.
>
> It should be safe because the initial value of cur doesnt matter
>
> consider cur is set to NULL, this can already happen as get_pool()
> can always switch the whole buffer chain out making it NULL until it
> gets reinserted
>
> now consider its non NULL but wrong
> while (cur != last) will be true
>
> cur = avpriv_atomic_ptr_cas((void * volatile *)&pool->pool, last, NULL);
> will compare it against the actual correct value and just do an extra
> iteration
>
> but iam not insisting on this, it just looked inefficient to me how it
> was done
>
> [...]
You're right, it would work out as well.
This whole atomic thing is sometimes confusing me, personally i
probably would've used a mutex for the whole buffer pool.
More information about the ffmpeg-devel
mailing list