C++ REST SDK:异步任务与 C++11 多线程
C++ REST SDK: asynchronous tasks vs. C++11 multithreading
这是一个关于 C++ REST SDK 的异步任务特性的概念性问题(也可能是一个有点菜鸟的问题)。
在一个基本的应用程序中,我有一个客户端并执行多个请求,例如喜欢
http_client client(U("whatever"));
for(int i=0; i<100; ++i)
{
http_request request;
//fill the request
client.request(request).then([](http_response response) { /* do something*/});
}
(foor-loop只是表示经常发送请求,我并没有真正在我的代码中使用它)。
问题:
据我了解,异步任务库然后以并行方式处理这些传入请求——这意味着不是主线程以类似事件的方式处理所有任务,而是库以某种方式(--对我来说是不透明的--)将任务分配给底层线程池。我没听错吗?
如果前面的观点是正确的,那么有什么理由将REST SDK与C++的多线程能力结合起来。例如,再次采用上述循环,启动 10 个线程,并在每个进程中执行 10 次循环迭代。这有意义还是不必要?
此外,一般来说,有没有什么共同的模式应该通过 C++11 多线程功能来组合 ppl-capabilities?或者依靠 REST SDK 和引擎盖下的 ppl 可以更好地完成工作是否安全?
(说明:我也在cpprest discussion page上问过这个问题,不过这个论坛好像没人维护了。)
As far I understand, the asynchronous task library then handles those
incoming requests in a parallel way -- meaning that not the main
thread handles all tasks in an event-like fashion, but rather the
library assigns the tasks to an underlying thread pool in some (--to
me intransparent--) way. Did I get that correct?
是的,在 REST SDK 中,他们使用线程池来启动任务延续。在 windows 上,他们使用 Windows API 线程池函数(CreateThreadPool
、TrySubmitThreadpoolCallback
等)。在 Linux,他们使用了 Boost 一个。
If the previous view is correct, then is there any reason to combine the REST SDK with the multithreading capabilities of C++. For
example, taking again the above loop, start 10 threads and in each one
process 10 loop iterations. Does this makes sense or is it
unnecessary?
完全不用,平台自带线程池
Moreover, in general, are there any common patterns where one should
combine the ppl-capabilities by the C++11 multithreading feature? Or
is it safe to rely that the REST SDK and ppl under the hood get the
job done better?
嗯,task
的整个想法是抽象掉线程的使用。在处理许多并行任务时,线程不能很好地扩展。传统的方法是使用线程池不为每个新任务生成新线程。
ppl tasks 使您能够以更优雅的方式处理异步 IO。您将 CPU 绑定任务封装在 ppl::task
中,在这些任务中,您可以生成另一个异步 IO 操作,并在异步 IO 时使用 ppl::task::then
继续执行 CPU 绑定任务完成了。
该机制是 task-> aync IO -> continuation task-> async IO ->task
的链条,依此类推。当任务启动 IO 操作时,底层线程池会转到下一个任务。当异步 IO 完成时,它将继续任务排在线程池任务队列的末尾。
所以不,你不应该自己直接创建任何 std::thread
。但是,您确实想要使用 std::mutex
之类的同步对象,如果 您的任务访问任何 shread 资源。
------------------------------------
一个很好的奖励:
在 VC++ 上使用 visual studio 2015 RTM 及更高版本,您可以在任务上使用 await
并摆脱 then
:
http_client client(U("whatever"));
for(int i=0; i<100; ++i)
{
http_request request;
//fill the request
auto response = await client.request(request);
//do something with the response
}
-------------------------------------------- ------
一个糟糕的奖励:
根据我使用 REST SDK 的经验,它的性能非常差,不是您期望从 C++ 平台获得的性能。
这是一个关于 C++ REST SDK 的异步任务特性的概念性问题(也可能是一个有点菜鸟的问题)。
在一个基本的应用程序中,我有一个客户端并执行多个请求,例如喜欢
http_client client(U("whatever"));
for(int i=0; i<100; ++i)
{
http_request request;
//fill the request
client.request(request).then([](http_response response) { /* do something*/});
}
(foor-loop只是表示经常发送请求,我并没有真正在我的代码中使用它)。
问题:
据我了解,异步任务库然后以并行方式处理这些传入请求——这意味着不是主线程以类似事件的方式处理所有任务,而是库以某种方式(--对我来说是不透明的--)将任务分配给底层线程池。我没听错吗?
如果前面的观点是正确的,那么有什么理由将REST SDK与C++的多线程能力结合起来。例如,再次采用上述循环,启动 10 个线程,并在每个进程中执行 10 次循环迭代。这有意义还是不必要?
此外,一般来说,有没有什么共同的模式应该通过 C++11 多线程功能来组合 ppl-capabilities?或者依靠 REST SDK 和引擎盖下的 ppl 可以更好地完成工作是否安全?
(说明:我也在cpprest discussion page上问过这个问题,不过这个论坛好像没人维护了。)
As far I understand, the asynchronous task library then handles those incoming requests in a parallel way -- meaning that not the main thread handles all tasks in an event-like fashion, but rather the library assigns the tasks to an underlying thread pool in some (--to me intransparent--) way. Did I get that correct?
是的,在 REST SDK 中,他们使用线程池来启动任务延续。在 windows 上,他们使用 Windows API 线程池函数(CreateThreadPool
、TrySubmitThreadpoolCallback
等)。在 Linux,他们使用了 Boost 一个。
If the previous view is correct, then is there any reason to combine the REST SDK with the multithreading capabilities of C++. For example, taking again the above loop, start 10 threads and in each one process 10 loop iterations. Does this makes sense or is it unnecessary?
完全不用,平台自带线程池
Moreover, in general, are there any common patterns where one should combine the ppl-capabilities by the C++11 multithreading feature? Or is it safe to rely that the REST SDK and ppl under the hood get the job done better?
嗯,task
的整个想法是抽象掉线程的使用。在处理许多并行任务时,线程不能很好地扩展。传统的方法是使用线程池不为每个新任务生成新线程。
ppl tasks 使您能够以更优雅的方式处理异步 IO。您将 CPU 绑定任务封装在 ppl::task
中,在这些任务中,您可以生成另一个异步 IO 操作,并在异步 IO 时使用 ppl::task::then
继续执行 CPU 绑定任务完成了。
该机制是 task-> aync IO -> continuation task-> async IO ->task
的链条,依此类推。当任务启动 IO 操作时,底层线程池会转到下一个任务。当异步 IO 完成时,它将继续任务排在线程池任务队列的末尾。
所以不,你不应该自己直接创建任何 std::thread
。但是,您确实想要使用 std::mutex
之类的同步对象,如果 您的任务访问任何 shread 资源。
------------------------------------
一个很好的奖励:
在 VC++ 上使用 visual studio 2015 RTM 及更高版本,您可以在任务上使用 await
并摆脱 then
:
http_client client(U("whatever"));
for(int i=0; i<100; ++i)
{
http_request request;
//fill the request
auto response = await client.request(request);
//do something with the response
}
-------------------------------------------- ------
一个糟糕的奖励:
根据我使用 REST SDK 的经验,它的性能非常差,不是您期望从 C++ 平台获得的性能。