マルチコア時代に備えて本気でメモリモデルを理解しておこう - メモリバリア編 - - じゅんいち☆かとうの技術日誌
このエントリを読む前提条件として、マルチコア時代に備えて本気でメモリモデルを理解しておこう - リオーダー & finalフィールド 編 - - じゅんいち☆かとうの技術日誌を読んで、リオーダーとは何かを理解していることとします。 前回のおさらいをすると、 プログラムの実行順序は、リオーダーが許可される場合と禁止される場合がある。並行処理ではリオーダーを想定しなければ、処理結果の整合性が確保できない。(特にマルチプロセッサ環境) リオーダーを禁止して、可視性を保証する。(finalフィールドはコンストラクト時に完全に初期化され、コンストラクト後はスレッドから見えるようになる) でした。 リオーダーについて理解できたら、今度はメモリバリア命令でスレッド毎に扱うメモリと、大域のメインメモリとのメモリI/Oについて見ていきたいと思います。メモリバリアが理解できれば、以下のソース*1のスレッドがな
JavaでActorっぽいものを作ってみる - かとじゅんの技術日誌
前回 JavaでScalaの"アクターのようなもの"を作ろうということだったので、早速 作ってみました。目的は、Actorの概念に触れることで、並行処理プログラミングの勘所を学ぶことなので、その前提で読んでいただければと思います。 リソース共有モデルには限界がある 「オブジェクト指向プログラマが次に読む本 Scalaで学ぶ関数脳入門」には、複数のスレッド間でリソースを共有する「リソース共有モデル」の限界について触れています。 「リソース共有」モデルを前提としている限り、プログラムの規模が大きくなるに従って、並行処理にまつわる複雑さや問題に対処することが困難になってきます。 これに対して、もしスレッド間で同一リソースを共有しないで、協調処理を行うとしたらどうでしょうか。リソースを共有しなければ、データ不整合やデッドロックなどの、並行処理で問題とされていることを回避できるのです。メッセージパッ
Scalaのジェネリックスを学ぶ - かとじゅんの技術日誌
Scalaのジェネリックスを少し学んでみました。(なんか違うんじゃね？とかあれば、ツッコミお願いしますm(_ _)m) Javaのジェネリックスでは、型パラメータは共変/反変ではない Javaでこんなコードを書いてコンパイラに怒られたことないですか。 public interface Animal { } public class Dog implements Animal{ } public class App { public static void main(String[] args) { ArrayList<Animal> animals = new ArrayList<Dog>(); } } ArrayList<Animal> animals = new ArrayList<Dog>(); とすると、型がミスマッチとなります。 つまり、ArrayListのサブ型として、Arra
非検査例外に萌えるわけ - かとじゅんの技術日誌
検査例外はアジャイルやオブジェクト指向の考えに反するという事実 - じゅんいち☆かとうの技術日誌 タイトルは釣り度が強すぎかなー、、、まぁ、個人のブログなんで気にしないでくださいw ブログはカジュアルに書けばいいんですよ。タイトル付け失敗してもサーセンです。 「オブジェクト指向の考え」ではなく「オープンクローズド原則」に反するとしたほうがいいですね。 しかし、貶める気もない人に 貶めるという定義付けは いただけないなー。 で、そんなこんなで重量級をゲットしてもた。。 非チェック例外多用作戦のトレードオフ認識 - 都元ダイスケ IT-PRESS オブジェクト指向と型システムの狭間で例外を考える - プログラマーの脳みそ エントリをいただいたので、さらにまた考えてみました。 チェック例外の正当性を再検証する 最近、多くの人の尊敬を集めているBruce EckelやRod Johnsonといった
「検査例外はアジャイルやオブジェクト指向の考えに反するという事実」について一部誤解あり - かとじゅんの技術日誌
追記： id:Nagiseさんからエントリいただきました。 というわけで、ややしつこく感じられるかもしれないけど誤りだと思うところはツッコミを入れさせてもらいます。人に恨みがあるとかそういうわけじゃなくて、説に用事があるってところをご理解いただければ幸いです。 こちらも建設的な議論をしたいと思っているので、もちろん、そのつもりです。 中間のクラスが〜という話題は、開放閉鎖原則を破って境界面に変更を加えた場合に話であって、検査例外が開放閉鎖原則を破るわけじゃない。 なるほど。よくわかりました。 目的と手段で分離してみた場合、「開放閉鎖原則」を「検査例外」を使って破っているだけであって「検査例外」自体の存在が「開放閉鎖原則」を破っているわけでない。「開放閉鎖原則」を破るのは「非検査例外」でもできるわけで、直接の因果関係は成立しないということですね。これは、私の論じ方に問題あったようです。ここに
妻子持ちITエンジニアが、家族から理解を得るには - かとじゅんの技術日誌
うちの会社は、1ヶ月に1回土曜に集まって社内LT大会をやっている。 なぜこんなことをやっているかというと、ITをプロとして仕事として生業にしていくには自己研鑽が必要だからだ。これは先のエントリにも述べた通りだ。自己研鑽といっても、発表の機会もないと勉強の機会がないので、社内LT大会をすることに決めた。(みんな直前になって資料を作成するなんとかしないとねぇ。当日、寝不足で死にそうになっているのはよくないw） これは休日開催なので、参加するにはいろいろと調整が必要。特に私のような妻子持ちはつらいところだ。かといって、大事なイベント。なんとか都合をつけたい。 そういう時は、きちんと家族に理解を求めている。「これだけは参加させてください。不況時代を生き抜くために必要なんです。」真剣にそういうことをいって理解を得るw また、お子さんがいらっしゃるのなら、お子さんにもなんで土曜なのに仕事にいくのか？と
設計と実装の両輪 - かとじゅんの技術日誌
自分がC/C++で飯を食っていた 2001年ごろに某ゲーム機メーカでお手伝いすることなり、現場にいた外注メンバーもできる人ばかり。その同僚からデザインパターンとかって耳慣れない話を聞く。コンボジットとか、デコレータ作ってみましたとかいってるｗ 意味わかんねーよ的な迷い子ｗ 帰宅後必死に調べる。そして、GoF本がしばらくバイブルとなり典型的なパターン厨となる。 新たな気づきとしては、オブジェクト指向言語の実装機能(カプセル化、継承、多態)を理解した程度では、複雑な要件を実装していくことは困難だと体感した。何が必要かというと、デザインパターンなどを加味した上でのオブジェクト指向設計の力。 設計と実装の両面での考え方が必要 実装力というのは、クラスのAPIをどのように使いこなすかであって、設計力というのはクラスの構造や関連をどのように構成するかを決める能力だと思っている。設計は戦略であり、実装は
チェック例外がJavaにあってC#にない理由 - かとじゅんの技術日誌
例外の再考 - じゅんいち☆かとうの技術日誌 に引き続き、チェック例外がJavaにあってC#*1になぜがないか考察してみようと思います。 また、いろいろググっているとよい記事がありました。 なぜ C# の言語仕様に検査例外がないのか？という記事。 "Why doesn't C# have exception specifications?" http://msdn.microsoft.com/en-us/vcsharp/aa336812.aspx 基本原文読んでくださいね。私の英語力は当てにならないのでw ここで言及しているのは以下の項目。順におっかけてみよう。 Versioning Productivity and code quality Impracticality of having class author differentiate between "checked" and
例外の再考 - かとじゅんの技術日誌
愛する部下の一人がよいエントリを書いてくれたので、私も重い腰をあげてみたw Throwableについて本気出して考えてみた 2nd Season - 都元ダイスケ IT-PRESS 短時間で、ようまとめたなーw チェック例外は、Java以外の言語では聞いたことがないのですが。Javaが10年やってきて、これがベストプラクティスなら他の言語にも存在してもよいはず。なぜ使わないんだろう。。。ということで、例外を再考してみました。 例外をめぐる議論 何気にいろいろ調べていたら、こういうのがでてきました。2004年以降はRTE使っているよというのがこれか！？ Javaの理論と実践: 例外をめぐる議論 これはもう過去にされていた議論ですね。知らなかったですw Sunは、文書化されない例外は投げるべきでない。つまるところ、扱う例外はメソッドのthrowsにちゃんと明記する派。APIを使う側のユーザとし
wait, notifyはもう古い - かとじゅんの技術日誌
スレッドでシグナルを送受信する場合は、典型的にwait, notifyのAPIがよく使われてきました。 でも、Java5以降ではもう古いんですよ。そのやり方。concurrentパッケージにCountDownLatchというクラスがあります。これで同様のことがすごくシンプルに実現できるんです。(Seasar-usersでもwait/notify使った回答を投稿したのですが、Java5以降なら本当はこっちを使うべきです) java.util.concurrent クラス CountDownLatch たとえば、以下のような複数スレッドの開始シグナルと終了シグナルで同期する場合です。 CountDownLatch自身が保持しているカウント数 - countDownメソッドが呼ばれた回数でゼロなったとき、awaitメソッドが待機せず、それ以外は待機します。その特性を使って開始や終了のシグナルを実
例外の扱いについて その２ - かとじゅんの技術日誌
さて、異論、奇抜論を唱えてみようかと思っているじゅんいち☆かとうですw Clean Code アジャイルソフトウェア達人の技 作者: Robert C. Martin,花井志生出版社/メーカー: アスキー・メディアワークス発売日: 2009/05/28メディア: 大型本購入: 27人 クリック: 848回この商品を含むブログ (66件) を見る 非チェック例外の章から紹介。 C#にはそもそも言語仕様としてチェック例外がない。C++にもない。Ptyhon, Rubyにもないが堅牢なアプリケーションが実装できる。後に登場した言語ではチェック例外がないことをよく考えてくださいとw。 デメリットとしてはキャッチから例外をスローするメソッドの間でオープンクローズド原則に違反してしまうことだそうだ。つまり、throwsのことを言及しているようです。これはアプリケーションが変更に対して弱くなりがちで、t
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
