[Live-devel] triggerEvent() race condition

[Robert Smith]

I have been diagnosing an issue on a client's system which is streaming 
six live encoded H264 streams vis multicast RTP and I think the problem 
lies in the triggerEvent() method.

The problem is that some of the streams just stop after a while. I added 
extensive tracing to our code and identified that the last call to the 
library is triggerEvent() to notify the library of a new frame but 
deliverFrame() is never called after this.

I guess the problem is that triggerEvent() is not thread safe. My 
solution is to derive BasicTaskScheduler and wrap the triggerEvent() 
call with a mutex. I have yet to test that this fixes the problem.

I'm a bit confused though because I had thought that triggerEvent() was 
thread safe. e.g, based on the content of this thread:

http://lists.live555.com/pipermail/live-devel/2012-June/015296.html

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 and 
this won't be atomic.

Regards,

Robert Smith.