异步委托VS主题 [英] Asynchronous delegates vs Threads
问题描述
与异步委托（回调）更换线程（线程池不是线程）。
Replacing Threads (not ThreadPool Thread) with Asynchronous Delegates (Callbacks).
我的情景：产生一个线程/ del.beginInvoke（）每个客户端
My Scenario: Spawn a Thread/del.beginInvoke() per Client.
据我，
原因
- 需要再次回调回调通过/呼叫代理通知
- 避免线程开销，（与会代表使用线程池线程）
- 传递参数（避免到对象），需要从方法的返回值。
纠正我，如果上述的原因是错误的。
Correct me if above reasons are wrong.
- 是其他原因？
- 什么情况下我究竟需要做的一些东西与异步与会代表认为
线程不能？结果
3.性能？
示例
public delegate void SendCallbackType();
SendCallbackType senderdel= new SendCallbackType(SendData);
public void StartSend() // This method Could be Called more than 700 times (Thread per Client)
{
senderdel.BeginInvoke(SendCallback,null);
// (or)
Thread t = new Thread(new ThreadStart(ThreadSend));
t.IsBackground = true;
t.Start();
}
//Async Delegate
void SendData()
{
string data = QueData.DeQueue();
RaiseOnData(data); // Raise to event.
}
void SendCallback(IAsyncResult ar)
{
senderdel.BeginInvoke(SendCallback, null);
}
//Thread
void ThreadSend()
{
while (true)
{
string data = QueData.DeQueue();
RaiseOnData(data); // Raise to event.
}
}
从上面的哪个选项将是最好的。性能如何？
From the above which option would be the best. Performance ?
推荐答案
您的推理是正确的。异步委托使用线程的线程池，使他们应该更快比手动线程创建。不过要小心这个ASP.NET应用程序中。因为你会吃了那些通常使用ASP.NET服务请求和应用程序可能很快用完服务能力的工作线程。
Your reasoning is correct. Async delegates use threads from the thread pool so they should be faster compared to manual thread creation. Be careful though with this in ASP.NET applications. Because you will be eating up worker threads that are normally used by ASP.NET to service requests and your application might very quickly run out of servicing capabilities.
异步代表是罚款CPU密集型任务。对于I / O密集型任务（如阅读流，数据库调用和Web服务调用），你应该使用相应的类直接提供的的BeginXXX，EndXXX方法（流，SqlConnection的，Web客户端，...）。你冗长的I / O操作过程中不使用任何线程都这样。您正在使用 I / O完成端口这是在I / O密集型任务而言最好的事情。这将是数量级更好的性能和资源比线程的线程和池便宜。
Async delegates are fine for CPU intensive tasks. For I/O intensive tasks (such as reading streams, database calls and web service calls) you should use the BeginXXX, EndXXX methods offered directly by the corresponding classes (Stream, SqlConnection, WebClient, ...). This way you are not using any threads at all during the lengthy I/O operation. You are using I/O Completion Ports which is the best thing in terms of I/O bound tasks. It will be orders of magnitude more performant and resource cheap than any threads and pools of threads.
总结一下：
- 对于I / O密集型任务使用I / O完成端口。如果I / O密集型任务中包含了一个写得不好库中，不提供这种可能使用第三方物流的引入在.NET 4.0中。
- 对于CPU密集型任务使用已介绍了.NET 4.0的TPL。
如果你没有.NET 4.0使用线程池，除非你正在写在这种情况下，你可能会采取手动线程创建ASP.NET应用程序。
And if you don't have .NET 4.0 use thread pool unless you are writing an ASP.NET application in which case you might resort to manual thread creation.
在总体上是很好的做法，开始使用 TPL 并定位你的方法是这样的任务你已经准备好了.NET 4.5，介绍了异步/等待关键字。
In general it is good practice to start using TPL and orient your methods as tasks so that you are ready for .NET 4.5 which introduces the async/await keywords.
这篇关于异步委托VS主题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
