> On Dec 19, 2020, at 7:04 PM, 单铭铭 <[email protected]> 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/
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
