[Live-devel] triggerEvent() race condition

[Robert Smith]

Maybe it's atomic on a single core CPU but it's not going to be safe 
with multicore CPU's.

Having thought about it some more, I don't think it's enough to just 
protect calls to triggerEvent() because 'fTriggersAwaitingHandling' is 
still modified by BasicTaskScheduler::SingleStep().

I'm not just speculating! but this problem can take hours to show it's 
self so I need to run the test for a long time to be confident that it's 
fixed. I have only protected the triggerEvent() method but I guess the 
chance of it failing now will be much lower because the task scheduler 
thread is probably waiting in a select() call most of the time.

I will have to implement my own task scheduler class to be completely 
confident though. I get that it's difficult to add synchronization in a 
portable way, but at least the documentation could be updated to 
highlight the problem.

Perhaps you could add an interface for a synchronization object and 
users could supply their own platform specific implementations.


On 03/16/2015 11:18 AM, Ross Finlayson wrote:
>> But I can't see how the implementation of triggerEvent() can be 
>> thread safe, e.g, the last line:
>>
>> fTriggersAwaitingHandling |= eventTriggerId;
>>
>> must load, modify and store the value at fTriggersAwaitingHandling
>
> It depends on the CPU architecture.  In many (if not most?) 
> architectures, it'll just be a single instruction.
>
> I'd put a mutex around that instruction, if there were a good portable 
> way of doing so (i.e., portable across Unix and Windows, and across 
> both old and new compiler versions).
>
> Feel free to put a mutex around your call to "triggerEvent()" - to see 
> if that solves your problem.  (In fact, you should have done that 
> first, before speculating on this mailing list :-)
>
>
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20150316/39ebd023/attachment.html>