- スレッド
- 同期プリミティブ
- 条件変数
- スレッドプール
- スレッドプール用ジョブ
- ScopedLock(スコープを抜けると自動でロック解除してくるクラス)
2012年4月30日月曜日
趣味ライブラリの機能一覧【スレッド】
スレッド関連で、実装した機能
Win32APIでのミューテックス、クリティカルセクション、セマフォの違い
セマフォ | ある処理があって、同時にその処理ができるスレッド数が限られている場合に使用。プロセスをまたいで排他制御可能 |
ミューテックス | ある処理があって、同時にその処理ができるスレッドが一つだけに限られている場合に使用。プロセスをまたいで排他制御可能 |
クリティカルセクション | ある処理があって、同時にその処理ができるスレッドが一つだけに限られている場合に使用。プロセスをまたいで排他制御不可能 |
基本的に処理速度は、クリティカルセクション > ミューテックス。
※ プロセス=タスクマネージャを開いて、プロセス一覧に表示される単位。
2012年4月25日水曜日
チケットの粒度はどのくらい? チケットを完了にできる人は誰?
どうもです。TECOです。しがないゲームプログラマーです。
突然ですが、現在自分が所属しているプロジェクトではチケット駆動でタスク管理しているのです。
今回、そこにちょっと気になることがあるので書き留めておきます。
プロジェクトのメンバーは数十名である。
プロジェクトは数名規模の複数の班で構成されている。
班には班長がいて、もちろん班長も実作業を抱えている。
まぁ、そこまで険悪な仲ではない。
チケット駆動でタスク管理をしている(Trac、Mantis、Redmineなどを利用)
うちのプロジェクトでは、タスクをチケット化したら一つのルールがあるのです。
そのチケットを完了にする権利を持っているのはその担当者が所属する班の班長である。
このルールの縛りで仕事をするということは、つまり以下のことを意味します。
チケットが増えるとそれに比例して、班長に「完了にするための作業」が発生してしまう。
つまりは、管理コストが増える!!
するとだ、以下のことが発生!!
チケットが増えれば増えるほど、班長の管理作業時間が増えて実作業時間が減るのだ。
ということは、最悪班長の作業がパンクしそうになるとチケット管理がおろそかになる!?
すると、以下のようなことが起こりかねない。。。
実作業者はチケットの粒度を大きくして班長の「完了にするための作業」を減らす
そんなことになれば、今度は以下の問題が発生する恐れががが
小さな粒度のチケットを発行しづらくなる
すると小さな粒度のタスクは、作業担当者の記憶の中に残っている、付箋に書いて壁に貼ってある、ローカルサーバーで起動している別のタスク管理ツールで管理している、などして作業担当者のタスク作業抜けが起きてないことを神に祈らなければならなくなる。
1.「作業粒度」はどのくらいの粒度で行うのがベストなの?
2. 「チケットを完了にできる権利」は誰が持っているのがベストなの?
それぞれの個人的見解は以下の通り。
1. 5分で終わるようなものからチケット化できるようにする。
2. チケットの内容によって完了にする権利を持ってる人を変える。(作業担当者自身、仕様担当者、班長)
う~ん、でも実際どうするのが良いのだろう。。。
突然ですが、現在自分が所属しているプロジェクトではチケット駆動でタスク管理しているのです。
今回、そこにちょっと気になることがあるので書き留めておきます。
前提
プロジェクトのメンバーは数十名である。
プロジェクトは数名規模の複数の班で構成されている。
班には班長がいて、もちろん班長も実作業を抱えている。
まぁ、そこまで険悪な仲ではない。
チケット駆動でタスク管理をしている(Trac、Mantis、Redmineなどを利用)
問題点
うちのプロジェクトでは、タスクをチケット化したら一つのルールがあるのです。
そのチケットを完了にする権利を持っているのはその担当者が所属する班の班長である。
このルールの縛りで仕事をするということは、つまり以下のことを意味します。
チケットが増えるとそれに比例して、班長に「完了にするための作業」が発生してしまう。
つまりは、管理コストが増える!!
するとだ、以下のことが発生!!
チケットが増えれば増えるほど、班長の管理作業時間が増えて実作業時間が減るのだ。
ということは、最悪班長の作業がパンクしそうになるとチケット管理がおろそかになる!?
すると、以下のようなことが起こりかねない。。。
実作業者はチケットの粒度を大きくして班長の「完了にするための作業」を減らす
そんなことになれば、今度は以下の問題が発生する恐れががが
小さな粒度のチケットを発行しづらくなる
すると小さな粒度のタスクは、作業担当者の記憶の中に残っている、付箋に書いて壁に貼ってある、ローカルサーバーで起動している別のタスク管理ツールで管理している、などして作業担当者のタスク作業抜けが起きてないことを神に祈らなければならなくなる。
つまり考えなければならないことは
1.「作業粒度」はどのくらいの粒度で行うのがベストなの?
2. 「チケットを完了にできる権利」は誰が持っているのがベストなの?
それぞれの個人的見解は以下の通り。
1. 5分で終わるようなものからチケット化できるようにする。
2. チケットの内容によって完了にする権利を持ってる人を変える。(作業担当者自身、仕様担当者、班長)
う~ん、でも実際どうするのが良いのだろう。。。
文字コード
Windows、Android、iOS対応のソースコードを書くなら
UTF8(BOM付き)
BOM無しだと、VisualStudioがアウト。
BOM付きも古いgccだとダメだったけど最近のgccだと大丈夫(なはず
UTF8(BOM付き)
BOM無しだと、VisualStudioがアウト。
BOM付きも古いgccだとダメだったけど最近のgccだと大丈夫(なはず
2012年4月20日金曜日
2012年4月18日水曜日
Syntax Highlighter導入
以前のブログでは、これが導入できなかったのでブログを変えようと思ったのです。
なので、まずはSyntax Highlighterを使ってみる。
うまく行ったー!!
とりあえずメモっておきやす。
なので、まずはSyntax Highlighterを使ってみる。
サンプル
void testFunc() { printf("Hello World"); }
うまく行ったー!!
手順
とりあえずメモっておきやす。
- http://www.way2blogging.org/2011/03/how-to-add-syntax-highlighterv3-to.html
- Generate Scripts
- 言語を選んで、Generate
- 出力されたスクリプトをコピー
- Bloggerのダッシュボードからテンプレート
- htmlの編集
- <html>~</html>の間に4でコピーしたソースをペースト
- 新規投稿
- <pre class="brush:言語名(例:c++);">ソースコード</pre>
- 以上
これで以前より格段と書きやすくなったー!!
ではでは
2012年4月17日火曜日
登録:
投稿 (Atom)