| Message ID | 20171127043021.20321-2-atomnuker@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
On Mon, Nov 27, 2017 at 04:30:19AM +0000, Rostislav Pehlivanov wrote: > Atomics were entirely pointless and did nothing but slow and complicate > the process down. This could be improved further still but the main > objective of this commit is to simplify. > > Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com> > --- > libavfilter/avfilter.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) *_register() can be called by the user app in a unsyncronized way for example from a module like vlc used AFAIK. or from libs loaded by an application which use libavfilter or other internally. These registration functions should stay thread safe [...]
On 11/28/17, Michael Niedermayer <michael@niedermayer.cc> wrote: > On Mon, Nov 27, 2017 at 04:30:19AM +0000, Rostislav Pehlivanov wrote: >> Atomics were entirely pointless and did nothing but slow and complicate >> the process down. This could be improved further still but the main >> objective of this commit is to simplify. >> >> Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com> >> --- >> libavfilter/avfilter.c | 8 +++++--- >> 1 file changed, 5 insertions(+), 3 deletions(-) > > *_register() can be called by the user app in a unsyncronized way > for example from a module like vlc used AFAIK. > or from libs loaded by an application which use libavfilter or other > internally. > > These registration functions should stay thread safe I don't see why, your description is weak at best.
On 28 November 2017 at 20:23, Michael Niedermayer <michael@niedermayer.cc> wrote: > On Mon, Nov 27, 2017 at 04:30:19AM +0000, Rostislav Pehlivanov wrote: > > Atomics were entirely pointless and did nothing but slow and complicate > > the process down. This could be improved further still but the main > > objective of this commit is to simplify. > > > > Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com> > > --- > > libavfilter/avfilter.c | 8 +++++--- > > 1 file changed, 5 insertions(+), 3 deletions(-) > > *_register() can be called by the user app in a unsyncronized way > for example from a module like vlc used AFAIK. > or from libs loaded by an application which use libavfilter or other > internally. > > These registration functions should stay thread safe > > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Those who would give up essential Liberty, to purchase a little > temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > What variable actually needs to be protected?
On Wed, Nov 29, 2017 at 03:51:34AM +0000, Rostislav Pehlivanov wrote: > On 28 November 2017 at 20:23, Michael Niedermayer <michael@niedermayer.cc> > wrote: > > > On Mon, Nov 27, 2017 at 04:30:19AM +0000, Rostislav Pehlivanov wrote: > > > Atomics were entirely pointless and did nothing but slow and complicate > > > the process down. This could be improved further still but the main > > > objective of this commit is to simplify. > > > > > > Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com> > > > --- > > > libavfilter/avfilter.c | 8 +++++--- > > > 1 file changed, 5 insertions(+), 3 deletions(-) > > > > *_register() can be called by the user app in a unsyncronized way > > for example from a module like vlc used AFAIK. > > or from libs loaded by an application which use libavfilter or other > > internally. > > > > These registration functions should stay thread safe > > > > > > [...] > > > > -- > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > Those who would give up essential Liberty, to purchase a little > > temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin > > > > _______________________________________________ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > What variable actually needs to be protected? The linked list of registered "entities" That is if the addition is not synchronized by some means, an atomic exchange a mutex or something then a race can generally occur and only one addition might succeed or something else might get entangled This is in practical terms a very unlikely event to occur of course [...]
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c index b98b32bacb..6b98e77a8e 100644 --- a/libavfilter/avfilter.c +++ b/libavfilter/avfilter.c @@ -19,7 +19,6 @@ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA */ -#include "libavutil/atomic.h" #include "libavutil/avassert.h" #include "libavutil/avstring.h" #include "libavutil/buffer.h" @@ -599,8 +598,11 @@ int avfilter_register(AVFilter *filter) filter->next = NULL; - while(*f || avpriv_atomic_ptr_cas((void * volatile *)f, NULL, filter)) - f = &(*f)->next; + /* Iterate through the list until the last entry has been reached */ + do { + *f = filter; + f = &filter->next; + } while (*f); last_filter = &filter->next; return 0;
Atomics were entirely pointless and did nothing but slow and complicate the process down. This could be improved further still but the main objective of this commit is to simplify. Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com> --- libavfilter/avfilter.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)