Managed blocking

RE: Managed blocking

Matt — Fri, 18 Apr 2003 17:39:00 GMT

Can U provide an insight into Monitor.Wait. In one application we have, every once in a while, a call to Monitor.Wait causes 99% CPU usage later

RE: Managed blocking

Chris Brumme — Fri, 18 Apr 2003 18:15:00 GMT

I'm just guessing, but... If you are running on a multi-proc machine, Monitor.Wait will attempt to spin for a while if there is contention. First we busy-spin, then we spin using SwitchToThread so we don't consume a CPU, and then we eventually block efficiently on an OS primitive. On a uniproc, we obviously dispense with all this spinning since it would simply take the CPU away from the thread holding the lock. We are routinely revisiting those spin counts, since CPUs keep getting faster / the cost of bus activity changes / etc. Unfortunately, tuning the spin counts is an inexact science, since the optimum values also depend on how long the application holds the lock, the number of arriving waiters, etc. In a perfect world, the system would be self-tuning. We would adjust the spinning parameters for each lock based on historical hold times, the performance profile of your machine, etc. In reality, it's not clear whether this would be worth the effort. Instead, we assume that none of your locks are hot. If we are waiting for a lock, we expect to get it right now or very, very soon. And -- unlike the operating system -- we are prepared to sacrifice fairness to get better throughput on that lock. If you have hot locks, then we don't have the right design. But the solution isn't for us to change our design. The solution is for you to reduce the heat on your lock, perhaps by doing less work in the lock or by using finer grained locks to partition the work or some other standard technique. At least, that's our design point. Incidentally, I think you will find our lock performance is much better in the release of the CLR we just shipped. We did a bunch of work to improve the case where your lock never experiences any contention at all!

RE: Managed blocking

Matt — Mon, 21 Apr 2003 03:18:00 GMT

Thanks. We actually found the problem only seemed to occur when debugging with VS .NET 2002.

re: Managed blocking

Chad — Wed, 04 Feb 2004 01:12:00 GMT

I have been tasked with writing a multithreaded .NET app that spawns several threads and interacts with an STA COM object and processes results from that object. The threads should be STA.

I need to spawn these threads and wait for them all to complete and then return/exit.

What's the best way to do this? WaitHandle.WaitAll() won't work because I'm in an STA thread and all the pooled threads are STA.

I've tried having a thread counter and using Interlocked.Inc/Decrement and then checking to see if the count was 0 and firing a manual reset event, but it doesn't seem to be working. The event fires somehow before the count is 0. I can't observe it during debugging because it's a race condition which is eliminated by the slowness of the debugger.

Any thoughts?
Thanks,
Chad

re: Managed blocking

Chris Brumme — Wed, 04 Feb 2004 02:10:00 GMT

What a coincidence. Yesterday I posted a new blog that talks about pumping and apartments. That blog contains a section that explains why you can't do WaitAll on an STA, and suggests 3 different workarounds. In each case, the workaround has drawbacks. But you might find one of them works for your scenario. The full article is at http://blogs.msdn.com/cbrumme/archive/2004/02/02/66219.aspx.

Thread.Sleep vs. Thread.CurrentThread.Join

xin — Sun, 22 Aug 2004 09:27:00 GMT

Ist Thread.Sleep(Int32) schlecht? | hilpers

Ist Thread.Sleep(Int32) schlecht? | hilpers — Tue, 20 Jan 2009 17:00:40 GMT

PingBack from http://www.hilpers.com/260969-ist-thread-sleep-int32-schlecht

A question about a while (true) loop | keyongtech

A question about a while (true) loop | keyongtech — Thu, 22 Jan 2009 05:59:54 GMT

PingBack from http://www.keyongtech.com/679169-a-question-about-a-while

cbrumme s WebLog Managed blocking | Insomnia Cure

cbrumme s WebLog Managed blocking | Insomnia Cure — Sat, 13 Jun 2009 09:43:36 GMT

PingBack from http://insomniacuresite.info/story.php?id=10179