何やら最近、自分の周りではドラ焼きブームが燃焼している様である。
タイ焼きでもタコ焼きでもなく、ドラ焼きが、であるのだ。
ドラ焼きイコールドラえもんに直結する世代には想像し易いかもしれないが、
実際にはドラ焼きをドラえもんの様に山ほど食べると胸焼けがするもので、
お土産に頂いたドラ焼きを食べるならせいぜい日に１つでありましょう。
世の中には趣向を凝らし一風変わったドラ焼きお土産が存在し、
あんこ味クリーム味セットなる、それ片方ドラ焼きか？的な一品を頂いた際、
これが開封された状態で皿に盛りつけられ、しかも一つは食べられていた事がありました。
残るは一つ。しかし中身が判らない！
これはまさにシュレーディンガーのドラ焼き！
パッと見は中身の味が判らない残された一つのドラ焼きでありますが、
離散的にクリームかあんこかという状態に対し、
量子力学的には白黒二つの状態である可能性が中間的に存在しているワケで、
「クリームのドラ焼きなんざ喰いたくはないのだが、喰う」
という波動関数を与えるまでは、ドラ焼きの味は確定しないじゃないか！
もういっそ、二つの状態が重なり合っていて欲しいと願うも、
それじゃ単に白あんドラ焼きじゃないかッと嘆く。
お茶が冷め始めた頃に漸く腰を上げ、クリームを引く可能性の低さを信じながら、待望の一口頬張る。
なんと言うことだ。
クリームが溢れ落ちた。
週明け一発目からかなりの痛さの様な気がしますが、今日も元気に生きてるTeamDyquemで御座います。
皆様こんにちは。
なにせ月曜日というものはアレですよ。土日を挟んで二日ぶりに現実世界へログインしますからね。
足取りがおぼつきません。早く脳内へログアウトしたい所でございます。
先日、新作をAppleへ提出致しましたよ。
年末はAppleホリデーで審査が止まる事に加え審査ラッシュで混んでいるとの噂もありますが、
なんとか年内リリースが叶えばと思います。
さて、本日はスレッド排他処理よもやま話など。
追記
以下は、NSURLConnectionを別スレッドを立てて使用する場合の話です
(それから、メインスレッドからNSURLConnectionを使用した様な表現を削除しました)
ご指摘、有り難うございました。
ネットワークからデータを受信する場合通常は非同期通信を選択する事になり、
以下の様にデータ受信終了デリゲートで待つわけですが、
そのデータに対しこのメソッドの中で何かを行うのは好ましくありません。
特に、UI系を操作してはいけません。
-( void )connectionDidFinishLoading:( NSURLConnection* )connection
{
// データ受信終了
// 但し、ここではデータそのものをどうこうしない。
// [ tableView的な何か reloadData ]; 等、UIへのアクセスも行わない
}
UIを握るのはメインスレッドであり、UITableView::reloadData 等はスレッドセーフではありません。
受信したデータの排他処理を行うのも面倒でしょうし、これら全てメインスレッドにて行う形が適切でしょう。
結局は排他処理実装かよッ、となりそうな何やら面倒くさそうな言い回しですが、
しかしこの辺りは流石の簡単Cocoa。超素敵な機構が御座います。
●受信スレッドが呼んだデリゲートから、メインスレッドの受信処理をリクエスト
// データ受信終了
-( void )connectionDidFinishLoading:( NSURLConnection* )connection
{
// メインスレッドの適切なメソッドコールをリクエスト
[ self performSelectorOnMainThread:@selector( updateMyData )
withObject:nil
waitUntilDone:YES
];
}
// ↑selfの部分は、基底クラスや他のインスタンス等、アプリの仕様に従い適時使い分けて下さい
// 更新処理 こんなメソッド名じゃなくて良いですが
-( void )updateMyData
{
// 受信したデータに対し、お好きな処理を
好きな処理;
// 必要ならUI等を更新
[ tableView的な何か reloadData ];
}
受信の為に起動されたスレッドは受信の仕事に特化させる形が良いでしょう。
受け取ったデータそのものは本来の持ち主が処理するという、役割分担の徹底が大切ですね。
シリーズ記事まとめ
■Aニュース、ガジェット通信 寄稿記事
「『連載.jp』寄稿「ゲームプログラマが語る「プロ棋士に勝ったAIは、タクシー基本無料化をもたらす？」」」
「『Aニュース/ガジェット通信』寄稿「ゲームプログラマが語る ”買わない理由”がもたらす充足感と、開発者達の心理」」」
「『Aニュース/ガジェット通信』寄稿「ゲームプログラマが語る アップデート版に潜む開発者モラルハザード」」
「『Aニュース/ガジェット通信』寄稿「ゲームプログラマが語る ソフトやアプリと携帯ゲーム課金における経済行動学」」
「『Aニュース/ガジェット通信』寄稿「ゲームプログラマが語る。新しいゲーム機が定期的に生まれる理由」」
「『Aニュース/ガジェット通信』寄稿「ゲームプログラマが語る 楽しさの仕組み ゲームメカニクス」」
「『Aニュース/ガジェット通信』寄稿「ゲームプログラマが語る 3Dテレビとゲームの微妙な関係 その打開策」」
「『Aニュース/ガジェット通信』寄稿「ゲームプログラマが語る 無料アプリのビジネスモデルと舞台裏」」
「『Aニュース/ガジェット通信』寄稿「新発表ラッシュに見るクラウド大航海時代の幕開け」」
■ゲーム制作初心者さん向け系
ゲームプログラマが語る。なんちゃってリードプログラマにはなるな！ゲーム造りで放棄してはいけない大切な事
ゲームプログラマが語る。今さら聞けないフレームレートに纏わる話。秒間６０？１６ミリ？
ゲームプログラマが語る。「浮動小数点」と商業レベルで上手に付き合う方法
「ゲームプログラマが語る。ゲーム制作初心者の方へ小ネタ「クォータービュー入門」」
「ゲームプログラマが語る。「正しい乱数」が彩る確率世界とエンターテイメント」
「iPhoneアプリ、ゲーム制作初心者の方へ小ネタ「線分と円の交差」」
「iPhoneアプリ作者より、ゲーム制作初心者の方へ小ネタ「２Ｄベクトル」」
「iPhoneアプリ作者より、ゲーム制作初心者の方へ小ネタを一つ」
■「プロのゲームプログラマとして、ゲーム製作に関する書評を」シリーズ
ゲームプログラマが語る書評:「MMORPGゲームサーバープログラミング」を読んでみた
ゲームプログラマが語る書評:「ゲームプログラマになる前に覚えておきたい技術」を読んでみた
ゲームプログラマが語る書評:「ゲームエンジン・アーキテクチャ」を読んでみた
■個人でも出来る、マルチプラットフォーム開発関連
「ゲームプログラマが語る。iOSゲームをWinマルチプラットフォーム開発・その４」
「ゲームプログラマが語る。iOSゲームをWinマルチプラットフォーム開発・その３」
「iPhoneアプリ作者が語る。マルチプラットフォーム化その２・アトミック型定義のススメ」
「ゲームプログラマが語る。iOSゲームをWinマルチプラットフォーム開発・その１」
■リリースしました系
「PASTEL-ORBIT/TeamDyquemアプリ第19弾。ローグライク決定版「隣人は魔王」をリリースしました。」
「TeamDyquemアプリ第18段。ご当地バトルRTS「埼玉クエスト」をリリースしました。近隣の県を滅ぼそう(*-_-*) 埼玉以外でも遊べます #47app」
「アプリ新作「ネコりす マカロン」をリリースしました」
「埼玉県ご当地アプリ、「タッチ the さいたま」をリリースしました #47app」
「アプリ新作「ひよこガーデン」をリリースしました」
「TeamDyquem新作。結構真面目なアクションパズル「ネコりす」リリース」
「iPhoneアプリ作者が、iアプリ「泡リス女子部 for iアプリ」をリリースしました」
「自作iPhoneアプリ改良版、「ネコがゴミのようだネ：アーケード」をリリースしました」
「iPhoneアプリ作者が、「まりも育成」for iモードをリリースしました」
「iPhoneアプリ新作 「ナタ・デ・ネコ」 をリリースしました」
「秋刀魚は関係ないけれど、新作「i-Wishbone」リリース」
「アプリ新作「ネコがゴミのようだ」。プロモ動画をアップしてみた」
「「泡リス 女子部」、販売開始」
「AppBankにまりも紹介記事が！」
「ゲームプログラマとして参加。ご当地４７都道府県アプリプロジェクト #47app」
□ビジネス系
「ゲームプログラマが語るドコモiPhoneと、インフラから合法的に大金を抜くスキーム」
「ゲームプログラマが語る。秀丸エディタのビジネスモデル」
■ＳＦネタ系
「ゲームプログラマがＳＦを語る。意識はどこからやってきて、死んで、そして何処へ行く？」
「ゲームプログラマが語る。気の遠くなるスキもない程の、宇宙の話」
「iPhoneアプリ作者が語る。流れ星に馳せる真実」
「iPhoneアプリ作者が警笛。どこでもドアの使い過ぎには注意」
「iPhoneアプリ作者が語るSETI理論。異星人さんは何処！？」
- 関連記事
-
Theme:宇宙文明
Genre:サブカル
|
Google+
.
new
YouTubeチャンネル - TeamDyquem
Facebook - TeamDyquem
