[vlc-devel] [RFC] Atomic API

Felix Abecassis felix.abecassis at gmail.com
Fri Dec 6 15:41:58 CET 2013


2013/12/6 Rafaël Carré <funman at videolan.org>
>
>
> In fact it is my fault for not using atomic_bool in android/thread.c
> The vlc_atomic.h header only declares atomic_bool but does not use it,
> contrary to vlc_atomic_t which is used by several functions.

I think it's because the types atomic_* are ready to use with the
generic operations atomic_store/atomic_load, etc.
Variables of type vlc_atomic_t are less flexible since the type can
only be uintptr_t.

>
> This works but it could be a bit counter intuitive, even if relying on
> the size of a type without using sizeof() should be frowned upon.

For a given combination of compiler/target we might be able to
specialize the types safely.

>
> I favor option 2, remove size 1 atomic types (16 bits works with msvc btw?)

Actually it looks like some 16 bits operations are also only supported
in desktop mode, e.g.:
http://msdn.microsoft.com/en-us/library/windows/desktop/hh972641%28v=vs.85%29.aspx

Minimum supported client: Windows 8 [desktop apps only]


2013/12/6 Rémi Denis-Courmont <remi at remlab.net>:
>
> No. vlc_atomic_t is the old deprecated interface just waiting for someone to
> remove it.
Ah, we were wondering why there was two sets of operations, thanks.

>
> But then, how is it that GCC is able to implement 1-byte atomic ops on the
> same architecture?
I don't know why there is this limitation, on x86 we should be able to
implement all operations for 1-byte to 8-bytes types. On ARM, I don't
know.
However it's also possible the target does not support the operation
but GCC provides it anyway. From the GCC documentation
(http://gcc.gnu.org/onlinedocs/gcc-4.4.5/gcc/Atomic-Builtins.html):

Not all operations are supported by all target processors. If a
particular operation cannot be implemented on the target processor, a
warning will be generated and a call an external function will be
generated. The external function will carry the same name as the
builtin, with an additional suffix `_n' where n is the size of the
data type.


-- 
Félix Abecassis
http://felix.abecassis.me

2013/12/6 Rémi Denis-Courmont <remi at remlab.net>:
> Le jeudi 5 décembre 2013, 22:47:23 Felix Abecassis a écrit :
>> 1) Fill the holes in the Interlocked API by implementing the missing
>> functions. We could use locks similarly to what is currently being
>> implemented in vlc_atomic.h when no builtin atomic operations are used.
>
> Locks should only be used on architecture that do not have any atomic
> operations (or lack compare-exchange).
>
>> 2) Replace the aforementioned occurrences of variables of type atomic_bool
>> and use the type vlc_atomic_t instead. Some modules take this approach for
>> similar variables. For instance android/thread.c has a variable
>> "vlc_atomic_t killed;" whereas win32/thread.c uses "atomic_bool killed;".
>> vlc_atomic_t uses the type uintptr_t (4 or 8 bytes).
>
> No. vlc_atomic_t is the old deprecated interface just waiting for someone to
> remove it.
>
>> 3) Disable atomic types of size 1 byte for this target. We could force the
>> types atomic_bool/atomic_char... to be of a larger size. For instance with
>> something like this:
>
> If the target instructions set lacks 1-byte atomic operations (and some
> certainly do), that would be the logical solution. That's the whole point in
> having separate types defined for atomic and non-atomic variables.
>
> But then, how is it that GCC is able to implement 1-byte atomic ops on the
> same architecture?
>
> --
> Rémi Denis-Courmont
> http://www.remlab.net/
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel



-- 
Félix Abecassis
http://felix.abecassis.me



More information about the vlc-devel mailing list