[過去ﾛｸﾞ]
Boost総合スレ part9 (981ﾚｽ)
Boost総合スレ part9 http://echo.5ch.net/test/read.cgi/tech/1275014987/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
391: デフォルトの名無しさん [sage] 2011/03/04(金) 18:30:11.33 これが後世に残るゴミレススパイラルの始まりであった http://echo.5ch.net/test/read.cgi/tech/1275014987/391
680: デフォルトの名無しさん [sage] 2011/10/30(日) 21:20:35.33 timed_join http://echo.5ch.net/test/read.cgi/tech/1275014987/680
731: デフォルトの名無しさん [sage] 2011/11/19(土) 02:13:30.33 >>724 C++03でのmoveのエミュレーションの限界であり仕様 ttp://www.boost.org/doc/libs/1_48_0/doc/html/move/emulation_limitations.html#move.emulation_limitations.assignment_operator http://echo.5ch.net/test/read.cgi/tech/1275014987/731
842: デフォルトの名無しさん [sage] 2012/02/11(土) 17:00:53.33 >>841 返信ありがとうございます。 管理側は仕事追加・終了許可時に、ワーカーのインスタンスそれぞれのメンバー変数であるconditionでnotifyすることで待ちを解除させています。 ワーカーは、管理側が仕事を追加すると通知を受けて仕事を開始するためにwhileループ内で待ちを行っています。（終了許可待ちと仕事待ちは共通のconditionとmutex） void Worker::run() { while (true) { TaskData* task = NULL; while (_taskBag->getTasks(&task)) { job(task); } if (_finishable && _taskBag->numTasks() == 0) { _mtx.unlock(); break; } _cond.wait(_mtx); } } ワーカーが複数いるので、mutexロック解除で待ち解除の通知を行うと、「仕事追加→いずれかのワーカーが仕事に着手」の後にmutexの所有権が管理側に戻ってこないかもしれないので難しそうです。 まぁ実装の仕方次第でmutexだけでもいけそうですが。 あとよくよく考えると_cond.wait(_mtx)の時に暗黙的に_cond.wait(mutex::scoped_lock(_mtx))のようになっているんでしょうか。 となると、ロックがwait解除後に再度かけられてしまうのはある意味当たり前ですね。 申し訳ありません。簡潔な文章で伝えるのがもの凄く難しいですねw http://echo.5ch.net/test/read.cgi/tech/1275014987/842
959: デフォルトの名無しさん [sage] 2012/06/24(日) 21:44:57.33 馬鹿には無理 http://echo.5ch.net/test/read.cgi/tech/1275014987/959
963: デフォルトの名無しさん [sage] 2012/06/28(木) 20:18:55.33 >>961 ごめん間違えたわ。親クラスでunique_ptrを返すように定義してあった場合、 手持ちのshared_ptrを返すにはって事だった。 thisかどうかはどうでも良かったわ。 http://echo.5ch.net/test/read.cgi/tech/1275014987/963
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.049s