[Live-devel] Total Event Trigger Number and Thread Safety

[Ross Finlayson]

> On Dec 19, 2020, at 7:04 PM, 单铭铭 <shanmingming at itssky.com> wrote:
> 
> I'm reading live555's UsageEnvironment related source codes. And I note that the implementation of EventTriggerId is u_int32_t, and every ID only has one bit set on and others off. Now I have some questions (to the default provided implementation of these classes):
> 
> (1). Does the default implementation can only handle different event triggers no more than 32 at the same time?

Because the definition of “EventTriggerId” (in “UsageEnvironment/include/UsageEnvironment.hh”) is “u_int32_t”, *all* implementations (not just the default implementation) support no more than 32 different event triggers.


> (2). Since the implementation is u_int32_t, and TaskScheduler::TriggerEvent function may be called outside the event loop, is there any thread-safety problem?

If “deleteEventTrigger()” (the only operation that clears an event trigger id bit) is called only from within the event loop thread, then the only potential problem is - as you note - that the “|=“ operation inside the implementation of "BasicTaskScheduler0::triggerEvent()” might not be atomic.  If this operation is not atomic, then, yes, it’s conceivable possible for the setting of an event trigger id bit to be ‘lost’, if another thread is also doing a “|=“ (on another bit) at the same time.


> Can I understand it as: The risk of a race condition is reduced, but it may occur under some circumstances.

Yes, I believe so.  However, I think that this risk could be eliminated entirely by replacing the code
	fTriggersAwaitingHandling |= eventTriggerId;
with
	do {fTriggersAwaitingHandling |= eventTriggerId} while ((fTriggersAwaitingHandling&eventTriggerId) == 0);

I might make this change in a future release of the code.


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