<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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...)<br>
</p>
<div class="moz-cite-prefix">On 2020/12/20 10:14, 单铭铭 wrote:<br>
</div>
<blockquote type="cite"
cite="mid:75756985-7dfa-4a22-4c8d-99f24028c037@itssky.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
For your explanation to Question (1),
<blockquote>
<pre class="moz-quote-pre" wrap=""><font color="#0080ff">Because the definition of “EventTriggerId” (in “UsageEnvironment/include/UsageEnvironment.hh”) is “u_int32_t”, <b class="moz-txt-star"><span class="moz-txt-tag">*</span>all<span class="moz-txt-tag">*</span></b> implementations (not just the default implementation) support no more than 32 different event triggers.</font>
</pre>
</blockquote>
<p>I don't think so. Total event trigger number can be incremented
by changing the implementation, by not assuming that <font
face="monospace">"EventTriggerId"(u_int32_t) </font>has only
one bit set on and others off. What I mean is, "<font
face="monospace">EventTriggerId</font>" 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 "<font
face="monospace">fd_set</font>, 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 "<font face="monospace">EventTriggerId</font>", just
like system socket's implementation. But if <font
face="monospace">"BasicUsageEnvironment0.hh"</font> is also
the not-to-modify public interface, then the limit can't be
changed since "<font face="monospace">EventTriggerId
BasicTaskScheduler0::fTriggersAwaitingHandling</font>" already
has type "<font face="monospace">EventTriggerId</font>", which
only has 32-bit to set to distinguish different events.</p>
<p>And</p>
<blockquote>
<pre class="moz-quote-pre" wrap=""><font color="#0080ff">do {fTriggersAwaitingHandling |= eventTriggerId} while ((fTriggersAwaitingHandling&eventTriggerId) == 0); // (a)</font>
</pre>
</blockquote>
<p>There may still be some risk that "<font face="monospace">fTriggersAwaitingHandling</font>"
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 "<font
face="monospace">BasicTaskScheduler::SingleStep</font>":</p>
<blockquote>
<p><font face="monospace">fTriggersAwaitingHandling &=~
fLastUsedTriggerMask; // (b)<br>
</font></p>
</blockquote>
<p>If the order of (a) and (b) is following:</p>
<blockquote>
<p>1. (b) Read.</p>
<p>2. (b) Modify.</p>
<p>3. (a) Read, Modify.</p>
<p>4. (b) Write back to <font face="monospace">fTriggersAwaitingHandling
</font>.</p>
<p>5. (a) Write back to <font face="monospace">fTriggersAwaitingHandling
</font>.</p>
</blockquote>
<p>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 <font face="monospace">fTriggersAwaitingHandling</font>'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.</p>
<p>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).</p>
<p><br>
</p>
<p>By mitshan.<br>
</p>
</blockquote>
</body>
</html>