Threading Best Practice Question

[Guest]

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.CommStream is a property that returns TcpClient.GetStream()

public void some method()
{
Dns.BeginGetHostAddresses(t[0].Exchange, new
AsyncCallback(EndingMXResolve), HelperState);
}

public void EndingMXResolve(IAsyncResult result)
{
IPAddress[] listedIPs=Dns.EndGetHostAddresses(result);
DeliveryHelper HelperState = result.AsyncState;

HelperState.MessageClient.BeginConnect(listedIPs, 25, new
AsyncCallback(EndingConnect), HelperState);

//nothing left to do...
}

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

}

______________Vs______________________


void some method()
{
Dns.BeginGetHostAddresses(t[0].Exchange, new
AsyncCallback(EndingMXResolve), HelperState);
}

public void EndingMXResolve(IAsyncResult result)
{
IPAddress[] listedIPs=Dns.EndGetHostAddresses(result);
DeliveryHelper HelperState = result.AsyncState;

HelperState.MessageClient.Connect(listedIPs,25);

//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.MessageClient.Connect(listedIPs,25);

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

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.CommStream is a property that returns TcpClient.GetStream()

public void some method()
{
Dns.BeginGetHostAddresses(t[0].Exchange, new
AsyncCallback(EndingMXResolve), HelperState);
}

public void EndingMXResolve(IAsyncResult result)
{
IPAddress[] listedIPs=Dns.EndGetHostAddresses(result);
DeliveryHelper HelperState = result.AsyncState;

HelperState.MessageClient.BeginConnect(listedIPs, 25, new
AsyncCallback(EndingConnect), HelperState);

//nothing left to do...
}

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

}

______________Vs______________________


void some method()
{
Dns.BeginGetHostAddresses(t[0].Exchange, new
AsyncCallback(EndingMXResolve), HelperState);
}

public void EndingMXResolve(IAsyncResult result)
{
IPAddress[] listedIPs=Dns.EndGetHostAddresses(result);
DeliveryHelper HelperState = result.AsyncState;

HelperState.MessageClient.Connect(listedIPs,25);

//once connected do a read;
}

 

[Guest]

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.

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.MessageClient.Connect(listedIPs,25);

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

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.CommStream is a property that returns TcpClient.GetStream()

public void some method()
{
Dns.BeginGetHostAddresses(t[0].Exchange, new
AsyncCallback(EndingMXResolve), HelperState);
}

public void EndingMXResolve(IAsyncResult result)
{
IPAddress[] listedIPs=Dns.EndGetHostAddresses(result);
DeliveryHelper HelperState = result.AsyncState;

HelperState.MessageClient.BeginConnect(listedIPs, 25, new
AsyncCallback(EndingConnect), HelperState);

//nothing left to do...
}

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

}

______________Vs______________________


void some method()
{
Dns.BeginGetHostAddresses(t[0].Exchange, new
AsyncCallback(EndingMXResolve), HelperState);
}

public void EndingMXResolve(IAsyncResult result)
{
IPAddress[] listedIPs=Dns.EndGetHostAddresses(result);
DeliveryHelper HelperState = result.AsyncState;

HelperState.MessageClient.Connect(listedIPs,25);

//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

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.

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.MessageClient.Connect(listedIPs,25);

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

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.CommStream is a property that returns TcpClient.GetStream()

public void some method()
{
Dns.BeginGetHostAddresses(t[0].Exchange, new
AsyncCallback(EndingMXResolve), HelperState);
}

public void EndingMXResolve(IAsyncResult result)
{
IPAddress[] listedIPs=Dns.EndGetHostAddresses(result);
DeliveryHelper HelperState = result.AsyncState;

HelperState.MessageClient.BeginConnect(listedIPs, 25, new
AsyncCallback(EndingConnect), HelperState);

//nothing left to do...
}

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

}

______________Vs______________________


void some method()
{
Dns.BeginGetHostAddresses(t[0].Exchange, new
AsyncCallback(EndingMXResolve), HelperState);
}

public void EndingMXResolve(IAsyncResult result)
{
IPAddress[] listedIPs=Dns.EndGetHostAddresses(result);
DeliveryHelper HelperState = result.AsyncState;

HelperState.MessageClient.Connect(listedIPs,25);

//once connected do a read;
}