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

[单铭铭]

I'm sorry that I set some font color to white, which may be invisible if 
background is white too (I use night mode so it's same...)

On 2020/12/20 10:14, 单铭铭 wrote:
> For your explanation to Question (1),
>
>     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.
>
> I don't think so. Total event trigger number can be incremented by 
> changing the implementation, by not assuming that 
> "EventTriggerId"(u_int32_t) has only one bit set on and others off. 
> What I mean is, "EventTriggerId" can range in { 1, 2, 3, 4, 5, ..., 
> 2^32 - 1 }, not just { 1, 2, 4, 8, 16, ..., 2^31 }. Take system socket 
> file descriptor as an example. Socket descriptor is usually 
> implemented by int(or other int-releated). We can assume that system 
> limit one process to 1024 simultanously openned file descriptor, then 
> socket descriptor can range from 1 to 1023 (not very precise), and 
> this is supported by implementation similar to your implementation of 
> event trigger, but with a bit recording system of "fd_set, which may 
> be 1024 bits size. I believe live555's event trigger upper limit can 
> be pushed by changing the implementation of the generation and 
> recording system of "EventTriggerId", just like system socket's 
> implementation. But if "BasicUsageEnvironment0.hh" is also the 
> not-to-modify public interface, then the limit can't be changed since 
> "EventTriggerId BasicTaskScheduler0::fTriggersAwaitingHandling" 
> already has type "EventTriggerId", which only has 32-bit to set to 
> distinguish different events.
>
> And
>
>     do {fTriggersAwaitingHandling |= eventTriggerId} while
>     ((fTriggersAwaitingHandling&eventTriggerId) == 0); // (a)
>
> There may still be some risk that "fTriggersAwaitingHandling" will be 
> corrupted. The code above can only ensure that the bit is really set 
> by "TriggerEvent" function, but it may corrupt other operation on it 
> inside event loop in "BasicTaskScheduler::SingleStep":
>
>     fTriggersAwaitingHandling &=~ fLastUsedTriggerMask;  // (b)
>
> If the order of (a) and (b) is following:
>
>     1. (b) Read.
>
>     2. (b) Modify.
>
>     3. (a) Read, Modify.
>
>     4. (b) Write back to fTriggersAwaitingHandling .
>
>     5. (a) Write back to fTriggersAwaitingHandling .
>
> And (a) operation is completed, but (b) is not, since (b)'s write 
> operation is overwrited by (a)'s write. I believe some protection to 
> fTriggersAwaitingHandling's Read-Write is needed. And if you decide to 
> change the implementation of event trigger(use other data structrue to 
> recording event as I describe above), the exclusive Read-Write 
> mechanism is still needed.
>
> For solution, I didn't come up some ideas. Maybe spinlock is possible, 
> but I'm not sure it can be implemented purely by normal C++(without 
> other library support).
>
>
> By mitshan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20201220/90abce6a/attachment.htm>