Asynchronous operations, pinning

RE: Asynchronous operations, pinning

Ian Griffiths — Wed, 07 May 2003 21:24:00 GMT

So is System.Windows.Forms.Control.BeginInvoke part of this model? This may seem like a stupid question, but actually I suspect the answer is "no". There are two forms of Control.BeginInvoke, and *neither* of them lets you pass the optional callback delegate. (You may ask "what about the first parameter - isn't that a delegate?" And the answer is "Yes, but that parameter is also there in the synchronous Invoke method - the async BeginXxx method is supposed to add an extra delegate according to this pattern.") This is aggravating as it makes it really awkward to call EndInvoke. You can't do it in the method called by the delegate passed in, because you'll then be saying "Please block until I return from the method I'm calling you from" - or to put it more succinctly "Please deadlock". So how are you supposed to call EndInvoke? Using a call to Delegate.BeginInvoke? Seems rather tedious... So, given that Control.BeginInvoke does not appear to fit into the normal .NET pattern for async invocation, does this mean we're off the hook with respect to calling EndInvoke?

RE: Asynchronous operations, pinning

Chris Brumme — Wed, 07 May 2003 22:41:00 GMT

Last night I sent an email to the WinForms folks asking this same question. Like you, I suspect the EndInvoke is optional on Control. (I looked through the code, but that's no substitute for a statement from the authors). As you say, this API doesn't quite match the managed async programming model anyway. I'll reply back as soon as I get official word.

RE: Asynchronous operations, pinning

Dmitriy Zaslavskiy — Thu, 08 May 2003 04:45:00 GMT

Chris could you provide some examples of unnecessary pinning.

RE: Asynchronous operations, pinning

Chris Brumme — Thu, 08 May 2003 05:39:00 GMT

I've seen a lot of people pinning Delegate instances, as I described above. I'm not aware of a circumstance where this makes sense. I've also seen apps explicitly pinning managed arrays of primitives like char arrays and int arrays, before making PInvoke calls. The same thing with String and StringBuilder objects. If the unmanaged callee only needs access to the buffer for the life of the call, then the PInvoke marshaling layer will generally pin it for that duration. So this can be a second example of unnecessary pinning.

RE: Asynchronous operations, pinning

Manoj — Thu, 08 May 2003 08:43:00 GMT

One of the issues with asynchronous execution is how impersonation works. Client request comes in, gets queued for async execution, worker thread picks up the request, now worker thread need to impersonate the client...

RE: Asynchronous operations, pinning

Dmitriy Zaslavskiy — Thu, 08 May 2003 17:06:00 GMT

Chris thanks, for your answer. But those examples where shown in tones of samples. What about class(es) containing arrays, will those get pinned as well?

RE: Asynchronous operations, pinning

Chris Brumme — Fri, 09 May 2003 04:49:00 GMT

Dmitriy, Generally, PInvoke will either copy your data to fixed memory outside the GC heap, or it will pin memory in the GC heap and expose those bytes directly to unmanaged code. In either case, you don't need to explicitly pin -- so long as access to these bytes is scoped to within the duration of the PInvoke call.

RE: Asynchronous operations, pinning

Chris Brumme — Fri, 09 May 2003 04:50:00 GMT

Manoj, I will be posting a new blog later this evening which discusses impersonation (a little) and transference of CAS information across async points (a lot).

RE: Asynchronous operations, pinning

Dmitriy Zaslavskiy — Fri, 09 May 2003 16:42:00 GMT

Thanks Chris. I think I got it now.

RE: Asynchronous operations, pinning

Chris Brumme — Tue, 13 May 2003 00:30:00 GMT

I just got the official word from the WinForms team. It is not necessary to call Control.EndInvoke. You can call BeginInvoke in a "fire and forget" manner with impunity.

re: Asynchronous operations, pinning

Sharpie — Mon, 12 Jan 2004 19:39:00 GMT

Regarding the advice to call EndInvoke on all delegates or face potential resource leakage, I believe this was poorly conveyed in the docs until 1.1, and even then only barely mentioned.

Be that as it may, can you not get around this limitation for Fire and Forget by using the [OneWay] attribute on your delegate? I believe that attribute optimizes away the baggage of a fire and forget async delegate by preventing the runtime from having to carry around the IAsyncResult, the potential exception instance and the state object. So in short it kind of eliminates not only the concern of leakage but most of what it would leak anyway, and one would expect that if you had numerous such delegates, you'd be putting less strain on the resources. Presumably these are for operations for which don't throw exceptions or for which you don't care about their end result.

Incidentally, if that doesn't solve it and you still want to program with a fire and forget model, Mike Woodard of Developmentor implemented a smart class that takes care of calling EndInvoke for you. It is not the most performant thing but in small doses it could solve your fire and forget blues.

But something tells me that [OneWay] should take care of that for you, no?

re: Concurrency, Part 13 - Concurrency and the CLR

Larry Osterman's WebLog — Fri, 25 Mar 2005 22:33:00 GMT

Introducing ICommunicationObject

Nicholas Allen's Indigo Blog — Thu, 23 Feb 2006 22:02:24 GMT

In the Windows Communication Foundation, there are a few classes that are so fundamental that they are...

blogging @ kafazov.net » Blog Archive » WinForms asyncronous programming model??????????????????? ????????????????????? ?? WinForms

Sun, 11 Mar 2007 16:05:57 GMT

PingBack from http://kafazov.net/blog/?p=116

ASP.NET Tip: How to avoid creating a GC Hole

ASP.NET Debugging — Thu, 25 Sep 2008 15:52:03 GMT

There are only a few things that can make a .NET process crash.  The most common one is an Unhandled

EndInvoke still required? | keyongtech

EndInvoke still required? | keyongtech — Thu, 22 Jan 2009 06:24:08 GMT

PingBack from http://www.keyongtech.com/433557-endinvoke-still-required

.NET Memory Management and GCHandle

From .NET Geek's Desk — Sun, 01 Mar 2009 10:59:25 GMT

GC Handle provides facilities to explicitly control and monitor the lifetime of an object in heap.Whenever

cbrumme s WebLog Asynchronous operations pinning | Insomnia Cure

cbrumme s WebLog Asynchronous operations pinning | Insomnia Cure — Wed, 10 Jun 2009 04:00:32 GMT

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