natsuの秘密基地です
カレンダー
| 03 | 2024/04 | 05 |
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |
カテゴリー
プロフィール
ＨＮ：
natsu
性別：
男性
趣味：
酒など
自己紹介：
ここに書かれていることはフィクションです。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
クリティカルセクションを作る、
っていうときに、
@synchronizedはとても便利だと思う。
@synchronized(self)
{
for(int m=1 ; m<=5 ; m++)
{
NSLog(@"ID:%d SPEAK %d", threadID, m);
}
}
なんていう例は、
どこでだって見れるけども、
@synchronized(self)っていった場合、
そのメソッドがいくつかのスレッドから、
呼び出されることを想定しているんだと思う。
まあ、スレッドをつかってごにゃごにゃと、
この間からやってわけなんですが。
私のやつは、
スレッドごとにオブジェクトを一つ作成し、
そのオブジェクトに対してメッセージを送ることによって、
スレッド上の処理を動かす。
っていう感じになっているんだけども。
こんな動き方はすごいと思った。
あるスレッドで作ったオブジェクトは、
ほんとにそのスレッドに乗っかってるんだもの。
NSConnection経由でメッセージが送れる。
で、そんな感じのつくりだと、
@synchronized(self)
なんて無意味であることがわかる。
実際無意味だったし。
私のNSObjectを継承するクラスからうまれた、
かわいいインスタンスオブジェクトは
@synchronizedを意識した実装などしていないので、
この鍵はNSObjectがもっているはず。
なので、スレッドのファクトリで、
NSObject *lockObject
をもっておいて、
スレッドを作る際に渡しておく。
で、鍵をかけたいところで、
@synchronized(lockObject)
する。
2010-05-31 15:11:39.522 lockTest[4411:1d03] ID:0 SPEAK 1
2010-05-31 15:11:39.531 lockTest[4411:1d03] ID:0 SPEAK 2
2010-05-31 15:11:39.532 lockTest[4411:1d03] ID:0 SPEAK 3
2010-05-31 15:11:39.533 lockTest[4411:1d03] ID:0 SPEAK 4
2010-05-31 15:11:39.533 lockTest[4411:1d03] ID:0 SPEAK 5
2010-05-31 15:11:39.535 lockTest[4411:3603] ID:1 SPEAK 1
2010-05-31 15:11:39.535 lockTest[4411:3603] ID:1 SPEAK 2
2010-05-31 15:11:39.540 lockTest[4411:3603] ID:1 SPEAK 3
2010-05-31 15:11:39.540 lockTest[4411:3603] ID:1 SPEAK 4
2010-05-31 15:11:39.541 lockTest[4411:3603] ID:1 SPEAK 5
2010-05-31 15:11:39.544 lockTest[4411:3e03] ID:2 SPEAK 1
2010-05-31 15:11:39.545 lockTest[4411:3e03] ID:2 SPEAK 2
2010-05-31 15:11:39.545 lockTest[4411:3e03] ID:2 SPEAK 3
2010-05-31 15:11:39.546 lockTest[4411:3e03] ID:2 SPEAK 4
2010-05-31 15:11:39.546 lockTest[4411:3e03] ID:2 SPEAK 5
うん。めいめいのスレッドでちゃんと最後まで用を足す。
途中でママは呼ばない。
@synchronized。
こいつは勘なんだけども、
中の人はmutexのような気がする。
もし、頻繁にロック、アンロックするならば。
キューに構造体のポインタを押し込むような処理ならば、
処理自体よりロックの方が時間がかかるかもしれない。
と思った。
それも、たくさんの件数のデータを
押し込み、取り出しするんなら、
わりと馬鹿にならない時間がかかるかもしれない。
まだ試してみるべきことはある。
PR
ある処理をするスレッドを３つ作り、
それを実行させていくといったとき。
で、その一連の処理は一つのセットで、
その処理を始めたら処理を走りきらないと、
ほかのスレッドで処理を始めたくないときとか。
たとえば、
あるデータの集合。
たくさんあるデータの処理を２つや４つのスレッドで分担すると、
CPUの複数のコアがちゃんとつかえてお得かも。
と考えたときなんか。
キューから読み込み、読み込んだものを消す。
で、処理する。
その前には当然キューに書き込むわけだけど。
キューに押し込むデータをまとめて、
キューに書き込んで、なんてしてるとき、
スレッドが切り替わったりなんてして見なさいな。
あーもう。
ってなるから。
Cocoaでスレッドセーフなキューがあれば、
私はちょっと幸せになれたんだと思う。
MutableArrayを使えば、キューなんて簡単に実装できるけど、
MutableArrayはスレッドセーフじゃないんですな。
MutableArrayを保護しながら使わないといけない。
キューにアクセスできるのは一つのスレッドだけで、
ほかのスレッドは終わるまで外で待っていないといけない。
トイレの個室には同時に一人までしか入ってはいけないんです。
ある例外を除いて。
トイレに入ったらロックしましょう。
少し話はそれるんだけども、
スレッドを３つ立てて、
その３つのスレッドで５回ログをはく。
なんて処理は、結局こんな結果になる。
2010-05-31 14:28:54.933 lockTest[4067:3603] ID:1 SPEAK 1
2010-05-31 14:28:54.934 lockTest[4067:3e03] ID:2 SPEAK 1
2010-05-31 14:28:54.930 lockTest[4067:1d03] ID:0 SPEAK 1
2010-05-31 14:28:54.935 lockTest[4067:3603] ID:1 SPEAK 2
2010-05-31 14:28:54.935 lockTest[4067:3e03] ID:2 SPEAK 2
2010-05-31 14:28:54.935 lockTest[4067:1d03] ID:0 SPEAK 2
2010-05-31 14:28:54.936 lockTest[4067:3603] ID:1 SPEAK 3
2010-05-31 14:28:54.936 lockTest[4067:3e03] ID:2 SPEAK 3
2010-05-31 14:28:54.936 lockTest[4067:1d03] ID:0 SPEAK 3
2010-05-31 14:28:54.938 lockTest[4067:3603] ID:1 SPEAK 4
2010-05-31 14:28:54.938 lockTest[4067:3e03] ID:2 SPEAK 4
2010-05-31 14:28:54.938 lockTest[4067:1d03] ID:0 SPEAK 4
2010-05-31 14:28:54.940 lockTest[4067:3603] ID:1 SPEAK 5
2010-05-31 14:28:54.940 lockTest[4067:3e03] ID:2 SPEAK 5
2010-05-31 14:28:54.941 lockTest[4067:1d03] ID:0 SPEAK 5
ログはき一回ずつ、仲良く交代している。
あえてトイレでは例えない。
ログを５回はききるまで、
スレッドが切り替わるのはいや。
っていったとき、
ログをはくfor文に入る前と、
出た後に、
ロックをかける処理と、
ロックを外す処理が必要になる。
さてさて。
いわゆるJISなんですが。
ここらあたりは文字化け御免で。
ルール１
漢字や半角カタカナとかの前にあるコードをおくこと。
そのコードは0x1B（いわゆるエスケープ文字）から始まる。
ルール２
漢字や半角カタカナを使い終わったら、あるコードをおき、
行の終わりまでにJIS X 0201-1976のラテン文字集合か
ASCIIに戻すこと。
っていうことがあるみたいなんで、
そんなコード。
例えば、
1B 24 42
とか、
1B 28 42
が入っていれば
JISと思えばいいんすよ。
ただ、これはUCS2に含まれているようなコードで、
すなわちそれはUTF-16で書かれている以下のような文字列、
☛⑂あかさたなはまやらわ✛⡂
なんかはJISっぽく見えるんだと思う。
まあ、こんな文字列はね。
見かける可能性なんてないと思うけど。
あるわけないよこんなの。
だから、
☛⑂⡂やっほー。元気ー？ こないだの品物は1200㌛⡂⑂☚
っていうUTF-16の文章は悪意があるんだよ。
うっさい。具合悪いわ！みたいな。
円で換算してから請求しろ！！みたいな。
Windowsのブラウザでちゃんと出るのか不安だ。
1B 2?はバリのほうの言葉が割り当てられてるんで、
バリのほうの文書はJISっぽいんだと思った。
ちなみに、
☛ 26 1B 右さしてる手の形。しかも黒い
⑂ 24 42 さすまたみたいな記号。
✛ 27 1B 十字な記号。
⡂ 28 42 クリリンのおでこにあるようなやつ。
㌛ 33 1B クローネを一文字で。
だわさ。
クリリンのおでこは、
ハードウェアな人が使いそうな予感。
Windowsのブラウザでちゃんと出るのか激しく不安だ。
ここらあたりは文字化け御免で。
そんなこんなで、ちょっと怖いよね。
だもんで、UTF-16チェックをした後に
JISチェックをするようにしようと思った、
今日という肌寒い日。
どっか雹がふってたらしいよ。