asynchronous programming model with BeginRead...EndRead

  • Thread starter Thread starter Tony Johansson
  • Start date Start date
T

Tony Johansson

Hi!

Here I have a simple program that is using asynchronous programming.
As you know there are three styles of programming with Asynchronous
Programming Model(APM) to deal with handling the end of the call in an
asynchronous call: wait-until-done, polling and callback.
In this example I use the Rendezvous model Wait-Unit-Done Model.
When using this model(wait-unitl.done) I can't find point to use this when I
still must wait being blocked until the asynchronous call is complete.
So you are blocked until complete when using wait-until-done and you are
blocked if you use the traditional synchronous model to read a file.
Does someone agree with me in this matter ?

static void Main()
{
byte[] buffer = new byte[1000];
string filename = "test.txt";
FileStream fstrm = new FileStream(filename, FileMode.Open,
FileAccess.Read,
FileShare.Read, 1024, FileOptions.Asynchronous);
IAsyncResult result = fstrm.BeginRead(buffer, 0, buffer.Length, null,
null);
int numBytes = fstrm.EndRead(result);
fstrm.Close();
}

//Tony
 
Tony Johansson said:
[...]
So you are blocked until complete when using wait-until-done and you are
blocked if you use the traditional synchronous model to read a file.
Does someone agree with me in this matter ?

static void Main()
{
byte[] buffer = new byte[1000];
string filename = "test.txt";
FileStream fstrm = new FileStream(filename, FileMode.Open,
FileAccess.Read,
FileShare.Read, 1024, FileOptions.Asynchronous);
IAsyncResult result = fstrm.BeginRead(buffer, 0, buffer.Length, null,
null);
int numBytes = fstrm.EndRead(result);
fstrm.Close();
}
Click to expand...

Yes, it doesn't make much sense to use asynchronous programming in this
way UNLESS there are other operations that you can fit in between the
BeginRead and EndRead. But if you are not going to do anything between those
two calls, then use a simple synchronous call (Read(...)), so that your code
will be simpler and you won't waste a thread from the ThreadPool.
 
Alberto Poblacion said:
Tony Johansson said:
[...]
So you are blocked until complete when using wait-until-done and you are
blocked if you use the traditional synchronous model to read a file.
Does someone agree with me in this matter ?

static void Main()
{
byte[] buffer = new byte[1000];
string filename = "test.txt";
FileStream fstrm = new FileStream(filename, FileMode.Open,
FileAccess.Read,
FileShare.Read, 1024, FileOptions.Asynchronous);
IAsyncResult result = fstrm.BeginRead(buffer, 0, buffer.Length,
null, null);
int numBytes = fstrm.EndRead(result);
fstrm.Close();
}
Click to expand...

Yes, it doesn't make much sense to use asynchronous programming in this
way UNLESS there are other operations that you can fit in between the
BeginRead and EndRead. But if you are not going to do anything between
those two calls, then use a simple synchronous call (Read(...)), so that
your code will be simpler and you won't waste a thread from the
ThreadPool.
Click to expand...

If I compare the time it takes to complete this asynchronous call
IAsyncResult result = fstrm.BeginRead(buffer, 0, buffer.Length, null,
null);
int numBytes = fstrm.EndRead(result);

with the normal using the synchronous call.
I mean if it about the same why use asynchoroun(wait-until-done) when I can
use the synchronous call.
I don't gain anything to use the asynchronous (wait-until-done) model.
Do you agree with me ?

I mean asynchronous is good to use if you use the other Rendezvous
medel(polling or callback)

//Tony
 
Tony said:
If I compare the time it takes to complete this asynchronous call
IAsyncResult result = fstrm.BeginRead(buffer, 0, buffer.Length, null,
null);
int numBytes = fstrm.EndRead(result);

with the normal using the synchronous call.
I mean if it about the same why use asynchoroun(wait-until-done) when I can
use the synchronous call.
I don't gain anything to use the asynchronous (wait-until-done) model.
Do you agree with me ?

I mean asynchronous is good to use if you use the other Rendezvous
medel(polling or callback)

//Tony
Click to expand...

Yes, if you know up front that you want the operation to block, then
just use the synchronous calls.

There are scenario's imaginable where blocking may or may not be
required, or where a consumer can optionally pass in his own callback.
In such a case, you can always start out with a BeginXXX, and depending
on the requirement, pass in the callback or issue an EndXXXX on the same
thread. I haven't encountered such scenario's in my own code yet, so
can't say if this would result in cleaner code than (for instance)
explicitely branching between a BeginXXXX - EndXXXX combo and simply
calling XXXX, but it's an option nevertheless.

Also keep in mind that the authors of the documentation were perhaps
more aiming at completeness of describing the valid ways to end an
asynchronous operation than the usefullness of the various ways
 
As Alberto explained the goal of this asynchronous pattern is not to make
the BeginRead/EndRead pair quicker.

You can make your application quicker by starting an operation that keeps
running on its own (even if this operation is just waiting for some data to
be available). Meanwhile you do something else and later you read the result
(wether or not it has actually completed, waiting if needed).

I would suggest testing this pattern with web services calls rather than
disk IOs for full control.

You could easily create a sequential app that simulates :
- a call to a web service that takes 5 s
- another call to a web service that takes 5 s
- a local processing that takes 4 s
So this version will take 14 s.

Now if you do :
- a first asynchronous call (0 s)
- a second asynchronous call (0 s)
- the local processing (4 s)
- get the result of previous calls (will likely wait a bit as 5 s is longer
than 4)

It should take around 5 s. Then you can further test by making the local
processing longer than the web services call etc... You have full control
about all the elements on which you test this pattern...
 
Back
Top