<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 4, 2013 at 8:18 PM, Weeble <span dir="ltr"><<a href="mailto:clockworksaint@gmail.com" target="_blank">clockworksaint@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I was looking at SemaphoreSlim because it seemed to be causing us<br>
trouble. I think I identified our problem and submitted it as bug<br>
11598: <a href="https://bugzilla.xamarin.com/show_bug.cgi?id=11598" target="_blank">https://bugzilla.xamarin.com/show_bug.cgi?id=11598</a><br>
<br>
However, beyond the issue I describe there, I'm a bit unsure about a<br>
few aspects of the implementation. Could anybody look at it and tell<br>
me whether my concerns are warranted?<br>
<br>
<a href="https://github.com/mono/mono/blob/master/mcs/class/corlib/System.Threading/SemaphoreSlim.cs" target="_blank">https://github.com/mono/mono/blob/master/mcs/class/corlib/System.Threading/SemaphoreSlim.cs</a><br>
<br>
1. It's not clear what benefit it has over Semaphore. In .NET - as I<br>
understand it - the point of SemaphoreSlim is that in the case of low<br>
contention it doesn't actually use a WaitHandle and so avoids<br>
expensive calls into the kernel. It's only as a last resort that it<br>
actually allocates a WaitHandle and blocks on it. However, Mono's<br>
SemaphoreSlim always allocates a ManualResetEvent up-front, and<br>
signals it on every Release. Doesn't a ManualResetEvent have a kernel<br>
object and involve a context switch to signal it? Doesn't this nullify<br>
the only benefit of SemaphoreSlim over Semaphore?<br></blockquote><div><br></div><div>Yes, looks like our implementation could use some optimization.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


2. I don't understand the logic to decide how long to block for after<br>
spinning has failed. It seems to wait between 1 and deepSleepTime(=20)<br>
milliseconds. If a timeout has been specified it waits for the event<br>
until the timeout expires, clamped between 1 and 20 milliseconds. If<br>
no timeout has been specified (millisecondsTimeout=-1) it seems to<br>
always wait 1 millisecond. It seems that it would make more sense in<br>
that case to wait for the longest time possible, not the shortest.<br>
Have I misunderstood the code?<br></blockquote><div><br></div><div>Yes, it's confusing.<br></div><div style><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

3. I don't understand why it sets an upper limit on the wait time at<br>
all. Is that the only way to support cancellation tokens? If no<br>
cancellation token were provided, would it be better to wait as long<br>
as possible?<br></blockquote><div><br></div><div style>Yes, probably. Other optimizations for this are posible too.</div><div style><br></div><div style> </div></div></div></div>