471,325 Members | 1,282 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,325 software developers and data experts.

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.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;
}
Feb 15 '06 #1
3 4807
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

"RWF" <RW*@discussions.microsoft.com> wrote in message
news:EF**********************************@microsof t.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;
}

Feb 15 '06 #2
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.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

"RWF" <RW*@discussions.microsoft.com> wrote in message
news:EF**********************************@microsof t.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;
}


Feb 16 '06 #3
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*@discussions.microsoft.com> wrote in message
news:6B**********************************@microsof t.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.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

"RWF" <RW*@discussions.microsoft.com> wrote in message
news:EF**********************************@microsof t.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;
> }


Feb 16 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

136 posts views Thread by Matt Kruse | last post: by
6 posts views Thread by MPH Computers | last post: by
reply views Thread by Kelsang Wangchuk | last post: by
13 posts views Thread by John | last post: by
7 posts views Thread by Anthony Nystrom | last post: by
4 posts views Thread by Bob | last post: by
126 posts views Thread by Dann Corbit | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.