|
2003/11/20(木)
ラトドデラドン
|
|
|
わ〜い。今日はたくさんの疑問が氷解した。
1.notify(),wait()はObjectのメソッドである いや〜スレッドのメソッドだと思ってはまってた。つまりこれは排他的にアクセスさせてもらっているObjectのものを使うわけだ。全てのObjectがロックの管理機構を持っているとは驚き。
というわけだから、モニタっていうのはsynchronized修飾したメソッド中ではthisで、synchronized(Object){}ブロックでは指定したObjectで、notify,waitはモニタのものを呼び出さないと確実に例外が起きるというわけか。やっとわかったぞ。
2.実はCanvasにはバックバッファ機構がある。 今までAppletのpaint()メソッドと計算スレッドの間でどうやって同期とろうかとさんざん悩んでいたのが馬鹿みたい。これでpaint()で重い計算をする、とかいうサンプルプログラム以外であり得ない書き方ともおさらば。
http://f18.aaacafe.ne.jp/~ruke/TDFH/TwoDegreeOfFreedomHuriko.htm http://f18.aaacafe.ne.jp/~ruke/TDFH/TwoDegreeOfFreedomHuriko.java
まあ実行結果は全然かわらないし若干遅くなっているけれどコードがやっと理想的なコードになった。Java使うならこういう感じでコーディングしたいな〜、と思っていたことがだいたい全て実現できた感じだ。(とはいえまだ少し野暮ったく感じられる所が残っていて、それはどれも、たくさんの変数の代入処理だ。ここはHurikoConfigurationみたいなクラスでも作って簡素かしよう。)
それはつまり言語仕様が抽象的なレベルでは非常に合理的であるということだろう。
しかしドキュメントでは同じ意味と書かれている記述で速度が異なったり、GUIまわりで環境依存のところがあったり、ドキュメントからすらスレッドに関する自信の無さが漂ってくる辺りはちょっと悲しい。
とはいえこれは現在のPCのアーキテクチャが大昔からほとんど変わっていない所に無理やり巨大なOSがかぶせてあるからだろう。
GUIも、JAVA自体がグラッフィク機能を備えているのだからその上に構築すれば良さそうな物だが、それではパフォーマンスが低すぎるわけだ。
事実Swingはまさにその目的であるものであり、JAVAの上でのGUIとして非常に合理的に思えるにもかかわらず、まずこれに着いて語られるのは、遅い、ということだ。
やっぱり100% Pure Java PCが欲しいな。 ------------------------------------ AppretViewerで「再起動」をすると画面に何も表れないようになっていた。
destroy()中でCanvasオブジェクトを破棄してやるとうまくいった。 ------------------------------------ うわっ。いつのまにか駒場祭になってしまった。まだ11月上旬のつもりでいたのに…。
文芸部は静寂とNOISEを販売します。団体名は(6団体共同のため)ミニコミ懇親会となってますのでパンフレットとか見るときは間違えないでね。
JavaのGUIはWindowsネイテブのものと違って使って見る気にさせるなあ。でもレイアウトマネージャーは、あまり実用的な用途には使えない気が。でも、ウインドウサイズが変わった時に自動で処理してくれるのは捨てがたいから…というわけでGridBagLayoutを試し中。 ----------------------------------- はあ。筆箱学校に置いてきた。 その経緯がまぬけで。 階段教室で、筆箱を机から落としてしまった。それは一つ下の段の床に落ちた。 面倒だなと思った。 帰る準備を整えてから拾えば今いる段に登りなおす必要がなくなると思った。 拾うのを忘れて帰った。
ものぐさはいかん。
|
|
|