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

[Hansen Jan Rørgård]

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?

Best Regards

Jan Rørgaard Hansen
Lead Software Developer
Communication Solutions
Business Area Surveillance

Tel.:  + 45 3638 3000
Call me on: Skype
E-mail: jan.r.hansen at dk.saabgroup.com





Saab Danmark A/S
Porten 6
DK – 6400 Sonderborg                        
www.saabgroup.com

This e-mail is private and confidential between the sender and the addressee. 
In the event of misdirection, the recipient is prohibited from using, copying or 
disseminating it or information in it. Please notify the above if any misdirection.

-----Original Message-----
From: live-devel <live-devel-bounces at us.live555.com> On Behalf Of Ross Finlayson
Sent: 16. juni 2023 16:03
To: LIVE555 Streaming Media - development & use <live-devel at us.live555.com>
Subject: Re: [Live-devel] [EXTERNAL] Re: Possible concurrency issue with triggerEvent()

One more thing...

> On Jun 7, 2023, at 5:52 AM, Hansen Jan Rørgård <jan.r.hansen at dk.saabgroup.com> wrote:
> 
> triggerEvent called twice but eventHandler is called once:
> ===============================================
> Let's say NT has called createEventTrigger with EH1 and now has:
> ET1 : EventTriggerId1
> Then we can have the sequence:
> NT                                                     LT
> |                                                        |
> triggerEvent(ET1) ----------------> (TAW=0x00000001)
> triggerEvent(ET1) ----------------> (TAW=0x00000001)
>                                                           ---------------
>                                                                             | singleStep()
>                                                                             | handle ET1 by calling EH1
> 
> This might be intended behaviour

Yes, actually this is intended - and is not changed by the recent update to the code.  Calls to “triggerEvent()” with the same event trigger id are not intended to be 'queued up’.  Instead, you should wait until the event is handled before calling “triggerEvent()” (with the same event trigger id) again.

In a future release of the code, I will update the comment in the header file to make this clear.


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


_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel