[Live-devel] [EXTERNAL] Re: Possible concurrency issue with triggerEvent()

[Ross Finlayson]

> On Jun 20, 2023, at 8:39 AM, Hansen Jan Rørgård <jan.r.hansen at dk.saabgroup.com> wrote:
> 
> Thanks for the clarification regarding the intended behaviour of triggerEvent() ie. no queueing.
> 
> Also thanks for the update to fix the race condition. As std::atomic_flag::test() is a C++20 feature the compiler has to be fairly new. As far as I can see support is added in GCC from version 11.1 with the -std=c++20 option. For MSVC it is added in VS 2019 v16.11 with the /std:c++20 option.
> 
> Was it the intention that the fix should only be supported with C++20?

The intention was that the fix should be supported on any compiler that supports "std::atomic_flag” :-).  That seems to include all recent versions of clang, BTW.

But I have just installed a new version (2023.06.20) of the code that uses a similar implementation for event triggers even if "NO_STD_LIB" is defined.  In that case, "fTriggersAwaitingHandling" is now implemented as an array of "Boolean volatile"s, rather than as a (volatile) 32-bit bitmap.  This should make 'race conditions'  less likely (perhaps even impossible) even if you define "NO_STD_LIB".  (However, you should use the preferred, default implementation - that uses an array of "std::atomic_flag"s - if you can.)


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/