[gst-devel] [PATCH] SMP race condition in gstatomic.h

[Cameron Hutchison]

Once upon a time David I. Lehn said...
> 
> Good catch.  However, I'm not sure CONFIG_SMP is portable enough between
> *BSDs and Linux and Hurd and win32 and whatever else this code might run
> on.  Perhaps we need a configure check of some sort that we can force
> things to build for SMP.

The configure check should be to build for UP, and only if explicitly
forced by the developer.  Otherwise binaries that are shipped as part of a
distribution will fail to work on a SMP machine if built on a UP machine.

While it seems acceptable for distributors to ship two kernels, one for
UP and one for SMP, I doubt very much that they'd like to ship two
versions of all the userspace applications (well, not all, but
potentially all since they would not necessarily know which need SMP
variants).

If you were to have a ./configure flag to force UP, then you need to be
aware that all of the GST_ATOMIC_INT_... stuff most likely already
builds for SMP in all cases on linux - /usr/include/linux/config.h has
CONFIG_SMP set to 1 (well, in debian anyway, and probably in all cases
where /usr/include/linux is not symlinked into the kernel tree, which is
wrong anyway). You would probably want some way to make those
GST_ATOMIC_INT_... macros UP only if you had the option.