[Mono-bugs] [Bug 624849] BlockingCollection<T> takes 100% cpu when blocking for an element

[bugzilla_noreply at novell.com]

http://bugzilla.novell.com/show_bug.cgi?id=624849

http://bugzilla.novell.com/show_bug.cgi?id=624849#c7


--- Comment #7 from Jérémie LAVAL <jeremie.laval at gmail.com> 2010-07-31 20:36:13 UTC ---
(In reply to comment #6)
> This reduces cpu usage to alot on this machine. However, when comparing
> BlockingCollection (mono master) running on .net, with the built-in .net 4
> BlockingCollection, the mono version takes about 2% cpu, while the built-in
> does not show up at all (less than 1%).

This is all about tuning up number limit hence why I was asking. I will lower
it a bit more.

> I looked at the code and it seems there are no usage at all of any signaling or
> something. The .net version probably uses ManualResetEventSlim or SemaphoreSlim
> to actually sleep until it is signaled (by adding an element). The mono one
> just spins alot which is plain wrong. (spinning should afaict only be used in a
> short while before actually waiting, but this behaviour is built-in to
> ManualResetEventSlim and SemaphoreSlim)

The *Slim things are designed to not use kernel objects or too much kernel
level function so their stalling part is not as good as a real kernel object
which is exactly their purpose i.e. having an object with the same behavior but
for short lived wait not requiring any costly kernel operations. IMHO
BlockingCollection has kinda the same spirit that is having maximal throughput
between a producer (which when finished use AddingComplete) and a consumer
which isn't the case in your scenario where I wouldn't use such collection.

-- 
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.