Multi-Threading

Threading update...what I actually do...

Blog Author — Tue, 25 May 2004 00:03:00 GMT

Should mention I suppose the I lied in yesterdays post on threading using .NET...mea cupla :-). In that post I mentioned using delegates for multi-threading and said that you always had to use EndInvoke to avoid a memory leak...well not quite, what i actually do is use the excellent AsyncHelper class by Mike Woodring, this supports this syntax:

CalcAndDisplaySumDelegate d = new CalcAndDisplaySumDelegate(someCalc.Add);
AsyncHelper.FireAndForget(d, 2, 3);

No EndInvoke required as it takes care of this using a DynamicInvoke internally. Well, saves a few lines of code!

Delegate.BeginInvoke() and memory leaks...

Blog Author — Thu, 20 Nov 2003 02:54:00 GMT

I'm getting increasingly involved in the world of Asynchrony and have been doing a bit of digging about into some of the pitfalls of multi-threading.
I came across an interesting one today involving the use of BeginInvoke without a corresponding EndInvoke when using delegates...many books (including the one I'm using most right now, the excellent Programming .NET Components by Juval Lowy) mention that a good way to fire events asynchronously (i.e., not blocking) is to simple call BeginInvoke on the delegate - cool seems easy enough!
Well, reading around a bit, I discovered this by Mike Woodring which contains this statement: "Starting with the 1.1 release of the .NET Framework, the SDK docs now carry a caution that mandates calling EndInvoke on delegates you've called BeginInvoke on in order to avoid potential leaks. This means you cannot simply "fire-and-forget" a call to BeginInvoke without the risk of running the risk of causing problems. "
Now, I can't find the bit in the docs which says that, but another article at O'Reilly mentions the same thing... Well, based on this evidence, it would seem to be a good idea to avoid this potential leak, luckily Mike's stuff has a handily little helper class which supports the 'Fire and Forget idiom' - dead easy, now I can have lovely fire and forget calls without worrying about unintended leaks :-)

UPDATE: Found the doc reference, if you have MSDN it's here, if not the on-line version is here

Memory Leak - solved - or 'When STAThread Goes Bad'

Blog Author — Tue, 18 Nov 2003 07:40:00 GMT

I posted a little while ago about an odd 'Memory Leak' I was having...well, after several days of trawling (and annoying Data Wanta who's excellent email component I was mistakenly blaming - sorry!), I finally found the answer! Turns out that the little [STAThread] attribute above the main class of the Comand Line app isn't so inoccuous after all - Dave pointed out this thread - apparently there's some sort of bug in .NET which can lead to what is effectively a leak when using multi-threading in a STAThreaded application!