Semantics of BeginXyz()...EndXyz()

[Markus Ewald]

Hi!

I'm designing a system for communicating with an USB device. Now I'm a
bit stuck with Microsoft's asynchronous operation concept in .NET. You
know, the stuff with a normal method (eg. Receive()) and two
asynchronous methods (eg. BeginReceive() and EndReceive()).

Now I'm wondering about the exact semantics of this concept. Maybe
someone with more experience can help me answer these questions:

- What happens if an error occurs during the asynchronous transmission?
Is it reported by EndReceive()?
- Do IAsyncResult.AsyncWaitHandle and IsCompleted both need to be set
regardless of the outcome of the operation?
- What about multiple simultaneous calls to BeginReceive()? Is this
allowed? Or can I decided whether to support it on a case-per-case basis?

Thanks,
-Markus-

 

[Markus Ewald]

Hello, Markus!

ME> - What happens if an error occurs during the asynchronous transmission?
ME> Is it reported by EndReceive()?

Yes, it can be reported via throwing an exception on EndReceive(...), or with an out parameter in EndReceive(...)

Hm, it makes sense, but I've never seen that described anywhere. Do you
indidentally still happen to know where you found that?

ME> - Do IAsyncResult.AsyncWaitHandle and IsCompleted both need to be set
ME> regardless of the outcome of the operation?

From the docs:
[...]

Alright, gues I overlooked that paragraph, sorry

So, AsyncWaitHandle and IsCompleted need to be set as callers will excepect appropriate (documented) behavior .

ME> - What about multiple simultaneous calls to BeginReceive()? Is this
ME> allowed?

Yes, every call to BeginReceive will spawn ( get thread from threadpool ) new thread.
However, callers typically will call BeginReceive/EndReceive sequentially

ME> Or can I decided whether to support it on a case-per-case basis?
You mean to block BeginReceive until previous operation is completed? If so, then BeginReceive will be the same as Receive...

I had planned on adding a timeout argument to the Receive() method, but
I guess that probably wasn't such a good idea after all. As I understand
it now, Receive() is supposed to return immediately. If less than the
requested number of bytes is available, only that much data is returned,
just like the Stream.Read() methods.

Thanks,
-Markus-

 

[Vadym Stetsyak]

Hello, Markus!

ME> Hm, it makes sense, but I've never seen that described anywhere. Do you
ME> indidentally still happen to know where you found that?

As an example of such behavior consider async socket operations. Socket.BeginReceive/EndReceive

ME> I had planned on adding a timeout argument to the Receive() method, but
ME> I guess that probably wasn't such a good idea after all. As I
ME> understand it now, Receive() is supposed to return immediately. If less
ME> than the requested number of bytes is available, only that much data is
ME> returned, just like the Stream.Read() methods.

Yes, Receive returns immediately if data is available, it returns number of received data, if there is no data - it blocks...
--
Regards, Vadym Stetsyak
www: http://vadmyst.blogspot.com