After showing a simple thread pool with Boost.Asio in the last post i’m going to have a look at doing the same thing with the threading facilities in C++11. The biggest difference is that we don’t have the Asio library so we have to reproduce the relevant functionality ourselves. The declarations remain mostly the same except that the ThreadPool class doesn’t have the io_service members anymore bu
C++11では<future>ヘッダが導入され、 簡単に非同期の処理が実装できるようになった。 以下では用途毎に実装方法をまとめる。 thread間での同期の話はせず、あくまで完全に非同期な処理についてまとめる。 戻り値が必要ない場合(Thread-per-message pattern) とりあえず非同期に実行できればいい場合。 実行時間を短縮するために複数の独立な処理を並列に実行するなどの応用が考えられる。 std::threadを使用する。最も基本的な使い方は以下の通りである: auto th1 = std::thread([]{ do_long_work(); }); do_another_things(); th1.join(); std::threadの引数に実行したい関数を渡す。 関数に引数を与えたい場合は、std::thread(func, arg)のように行う。 プログラ
本連載ではシステムコールプログラミングの例も掲載していく予定ですが、本記事ではLinuxに追加されたepollを採りあげ、インターネットサーバでのPthread利用と比較してみます。 はじめに マルチスレッドプログラミングが普及し、POSIX threadも制定され、Pthreadの利用は目新しいものではなくなりましたが、スレッドにまつわる迷信や誤った認識を、だいぶ減ったとはいえ、今でもたびたび耳にします。例として、 スレッドはプロセスよりも軽いので、多数作成しても軽快に動作する スレッドはプログラミングを簡単にしてくれ、1つの処理だけに集中できる などがあります。しかし、これらは常に真であるとは限りません。本記事ではマルチスレッドの概念や入門を繰り返すのではなく、その利用方法をHTTPサーバのサンプル実装を基に考察します。更にLinuxに追加された独自機能のepollインタフェースを用い
Worker Thread パターンは、スレッドをあらかじめ起動しておくことにより、スレッドの起動するコストを削減することと、スレッドの数を制御することが出来るパターンです。 Boost.Function を使ってある程度汎用的にするとこんな感じになりました。 // Worker Thread class thread_pool { private: std::queue<boost::function0<void> > queue_; boost::thread_group group_; boost::mutex mutex_; boost::condition condition_; public: thread_pool(int size) { for (int i = 0; i < size; i++) { group_.create_thread(boost::bind(&th
Worker Thread パターンでスレッドプールを作ってみた。 worker_thread.h #ifndef ANMELT_THREAD_WORKER_THREAD_H_INCLUDED #define ANMELT_THREAD_WORKER_THREAD_H_INCLUDED // Boost #include <boost/thread.hpp> #include <boost/shared_ptr.hpp> #include <boost/function.hpp> #include <boost/bind.hpp> #include <boost/noncopyable.hpp> namespace anmelt{ namespace thread { template<class Container> class worker_thread : boost::noncop
threadpool is a cross-platform C++ thread pool library. In general terms thread pools are an efficient mechanism for asynchronous task processing within the same process. They realise the thread pool pattern. A thread pool manages a group of threads in order to process a large number of tasks. Since multiple threads can be executed in parallel this approach may be very efficient regarding the over
ネットで調べてもあまり具体的なサンプルがなかったので、一通りの動きが確認できるサンプルになるよう気をつけた。 /* スレッドプールのサンプル */ #include <stdarg.h> #include <stdio.h> #include <stdlib.h> #include <pthread.h> #include <time.h> /** スレッドプール情報 */ struct { /** 実行中タスク配列 */ struct t_pool { /** タスク */ void* (*pFunction)(void*); /** タスクに渡すパラメータ */ void* pParameter; /** ExecutorのスレッドID */ pthread_t pId; }* atPool; /** 実行予定タスクのキュー */ struct t_task { /** タスク */
スレッドプール(thread pool)を実装するには、暇なときはthreadを寝かせておいて必要なときに起こす、というイベント通知の仕組みが必要になる。 UnixでC/C++で実装するときはpthreadの条件変数を使うのが普通だと思われるが、適当なファイルディスクリプタをopenしておいてread等でブロックさせる方法でも実装できそう。 どのようなやり方が一般的なのか、いくつか有名どころのOSSの実装を調べてみた。 libuvの場合 https://github.com/joyent/libuv 単純にpthread_cond_waitをつかっている 1 static void worker(void* arg) { struct uv__work* w; QUEUE* q; (void) arg; for (;;) { uv_mutex_lock(&mutex); while (QU
図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド・イベント駆動 コネクションN:スレッド1。epoll/kqueue/select を1つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える: サーバーにメッセージを送信 イベントハンドラを登録;このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す 1コネクション1スレッ
目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 386 記事 - 16 コメント - 576 トラックバック - 104 ニュース BlogRollするぐらいならトラックバックしてこい。 記事のカテゴリ .NET Framework オブジェクト指向 プログラミング全般 過去の記事 2008年9月 (3) 2008年8月 (1) 2008年7月 (1) 2008年6月 (3) 2008年5月 (2) 2008年4月 (1) 2008年3月 (1) 2008年2月 (20) 2008年1月 (8) 2007年12月 (16) 2007年11月 (2) 2007年9月 (3) 2007年8月 (1) 2007年7月 (5) 2007年6月 (1) 2007年5月 (
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く