Threading Best Practice Question

[RWF]

I have read that when using asynchronous IO it is best to keep all your
operations asynchronous. But why if there is nothing left do in the
AsyncCallback method other than to call an IO operation? Example:

//DeliveryHelper is just a class containg an TcpClient and other state
traced variables.
//HelpState.CommS tream is a property that returns TcpClient.GetSt ream()

public void some method()
{
Dns.BeginGetHos tAddresses(t[0].Exchange, new
AsyncCallback(E ndingMXResolve) , HelperState);
}

public void EndingMXResolve (IAsyncResult result)
{
IPAddress[] listedIPs=Dns.E ndGetHostAddres ses(result);
DeliveryHelper HelperState = result.AsyncSta te;

HelperState.Mes sageClient.Begi nConnect(listed IPs, 25, new
AsyncCallback(E ndingConnect), HelperState);

//nothing left to do...
}

public void EndingConnect(I AsyncReslut result)
{
//end connect;
//begin async read;

}

______________V s______________ ________
void some method()
{
Dns.BeginGetHos tAddresses(t[0].Exchange, new
AsyncCallback(E ndingMXResolve) , HelperState);
}

public void EndingMXResolve (IAsyncResult result)
{
IPAddress[] listedIPs=Dns.E ndGetHostAddres ses(result);
DeliveryHelper HelperState = result.AsyncSta te;

HelperState.Mes sageClient.Conn ect(listedIPs,2 5);

//once connected do a read;
}

[Vadym Stetsyak]

Generally, if you start Async operation you schedule a task on thread pool,
right?
Lets consider following scenario: there is great number of request thread
pool may quickly run out of free threads.
Then if you will introduce sync operation like

HelperState.Mes sageClient.Conn ect(listedIPs,2 5); Then threadpool thread will be busy completing sync request. In this
situation possibility to run out of threads is high.

OTOH if you will schedule operations via BeginXXX functions then possibility
to starve threads is lower, because threadpool thread will schedule
operation and return to pool immediately.
--
Regards, Vadym Stetsyak
www: http://vadmyst.blogspot.com

"RWF" <RW*@discussion s.microsoft.com > wrote in message
news:EF******** *************** ***********@mic rosoft.com...I have read that when using asynchronous IO it is best to keep all your
operations asynchronous. But why if there is nothing left do in the
AsyncCallback method other than to call an IO operation? Example:

//DeliveryHelper is just a class containg an TcpClient and other state
traced variables.
//HelpState.CommS tream is a property that returns TcpClient.GetSt ream()

public void some method()
{
Dns.BeginGetHos tAddresses(t[0].Exchange, new
AsyncCallback(E ndingMXResolve) , HelperState);
}

public void EndingMXResolve (IAsyncResult result)
{
IPAddress[] listedIPs=Dns.E ndGetHostAddres ses(result);
DeliveryHelper HelperState = result.AsyncSta te;

HelperState.Mes sageClient.Begi nConnect(listed IPs, 25, new
AsyncCallback(E ndingConnect), HelperState);

//nothing left to do...
}

public void EndingConnect(I AsyncReslut result)
{
//end connect;
//begin async read;

}

______________V s______________ ________
void some method()
{
Dns.BeginGetHos tAddresses(t[0].Exchange, new
AsyncCallback(E ndingMXResolve) , HelperState);
}

public void EndingMXResolve (IAsyncResult result)
{
IPAddress[] listedIPs=Dns.E ndGetHostAddres ses(result);
DeliveryHelper HelperState = result.AsyncSta te;

HelperState.Mes sageClient.Conn ect(listedIPs,2 5);

//once connected do a read;
}

[RWF]

Yep. I walked through the logic after I posted and realized the issue with
the threadpool. For some reason I was assuming a completely new thread was
being created outside the pool, which is of course not the case.

"Vadym Stetsyak" wrote:

Generally, if you start Async operation you schedule a task on thread pool,
right?
Lets consider following scenario: there is great number of request thread
pool may quickly run out of free threads.
Then if you will introduce sync operation like

HelperState.Mes sageClient.Conn ect(listedIPs,2 5);

Then threadpool thread will be busy completing sync request. In this
situation possibility to run out of threads is high.

OTOH if you will schedule operations via BeginXXX functions then possibility
to starve threads is lower, because threadpool thread will schedule
operation and return to pool immediately.
--
Regards, Vadym Stetsyak
www: http://vadmyst.blogspot.com

"RWF" <RW*@discussion s.microsoft.com > wrote in message
news:EF******** *************** ***********@mic rosoft.com...

I have read that when using asynchronous IO it is best to keep all your
operations asynchronous. But why if there is nothing left do in the
AsyncCallback method other than to call an IO operation? Example:

//DeliveryHelper is just a class containg an TcpClient and other state
traced variables.
//HelpState.CommS tream is a property that returns TcpClient.GetSt ream()

public void some method()
{
Dns.BeginGetHos tAddresses(t[0].Exchange, new
AsyncCallback(E ndingMXResolve) , HelperState);
}

public void EndingMXResolve (IAsyncResult result)
{
IPAddress[] listedIPs=Dns.E ndGetHostAddres ses(result);
DeliveryHelper HelperState = result.AsyncSta te;

HelperState.Mes sageClient.Begi nConnect(listed IPs, 25, new
AsyncCallback(E ndingConnect), HelperState);

//nothing left to do...
}

public void EndingConnect(I AsyncReslut result)
{
//end connect;
//begin async read;

}

______________V s______________ ________
void some method()
{
Dns.BeginGetHos tAddresses(t[0].Exchange, new
AsyncCallback(E ndingMXResolve) , HelperState);
}

public void EndingMXResolve (IAsyncResult result)
{
IPAddress[] listedIPs=Dns.E ndGetHostAddres ses(result);
DeliveryHelper HelperState = result.AsyncSta te;

HelperState.Mes sageClient.Conn ect(listedIPs,2 5);

//once connected do a read;
}

[Li-fan Chen]

Hi RWF,

I have read that when using asynchronous IO it is best to keep all your
operations asynchronous.
Yep. Async usually work on one or a set number of threads. The whole
exercise is to get unblockable jobs multiplexed onto a limited set of
threads efficiently--eliminating the cost of spawning new threads. [Free]
Thread starvation of the limited set of threads in the thread pool is the
result of having any long-running jobs--such as jobs with blocking calls.
Some thread pools accomodate this by starting more threads, but once you
spawn enough threads you lose the benefits of a thread pool because your
CPUs are busy baby-sitting the large number of user threads.

--
Li-fan Chen
Software analyst/developer, Entrepreneur
Markham, Ontario, Canada
"RWF" <RW*@discussion s.microsoft.com > wrote in message
news:6B******** *************** ***********@mic rosoft.com... Yep. I walked through the logic after I posted and realized the issue
with
the threadpool. For some reason I was assuming a completely new thread
was
being created outside the pool, which is of course not the case.

"Vadym Stetsyak" wrote:

Generally, if you start Async operation you schedule a task on thread
pool,
right?
Lets consider following scenario: there is great number of request thread
pool may quickly run out of free threads.
Then if you will introduce sync operation like

> HelperState.Mes sageClient.Conn ect(listedIPs,2 5);

Then threadpool thread will be busy completing sync request. In this
situation possibility to run out of threads is high.

OTOH if you will schedule operations via BeginXXX functions then
possibility
to starve threads is lower, because threadpool thread will schedule
operation and return to pool immediately.
--
Regards, Vadym Stetsyak
www: http://vadmyst.blogspot.com

"RWF" <RW*@discussion s.microsoft.com > wrote in message
news:EF******** *************** ***********@mic rosoft.com...

>I have read that when using asynchronous IO it is best to keep all your
> operations asynchronous. But why if there is nothing left do in the
> AsyncCallback method other than to call an IO operation? Example:
>
> //DeliveryHelper is just a class containg an TcpClient and other state
> traced variables.
> //HelpState.CommS tream is a property that returns TcpClient.GetSt ream()
>
> public void some method()
> {
> Dns.BeginGetHos tAddresses(t[0].Exchange, new
> AsyncCallback(E ndingMXResolve) , HelperState);
> }
>
> public void EndingMXResolve (IAsyncResult result)
> {
> IPAddress[] listedIPs=Dns.E ndGetHostAddres ses(result);
> DeliveryHelper HelperState = result.AsyncSta te;
>
> HelperState.Mes sageClient.Begi nConnect(listed IPs, 25, new
> AsyncCallback(E ndingConnect), HelperState);
>
> //nothing left to do...
> }
>
> public void EndingConnect(I AsyncReslut result)
> {
> //end connect;
> //begin async read;
>
> }
>
> ______________V s______________ ________
>
>
> void some method()
> {
> Dns.BeginGetHos tAddresses(t[0].Exchange, new
> AsyncCallback(E ndingMXResolve) , HelperState);
> }
>
> public void EndingMXResolve (IAsyncResult result)
> {
> IPAddress[] listedIPs=Dns.E ndGetHostAddres ses(result);
> DeliveryHelper HelperState = result.AsyncSta te;
>
> HelperState.Mes sageClient.Conn ect(listedIPs,2 5);
>
> //once connected do a read;
> }