┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.348 2010/10/20
■ I N D E X
┃
┣【いちばんいい並行戦略をたのむ】そんなロックで大丈夫か？
┃ ロックフリーアルゴリズムのご紹介
┣【PF】現場リーダーの心得 [29]
┗ 編集後記
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┣【いちばんいい並行戦略をたのむ】そんなロックで大丈夫か？
┗ ロックフリーアルゴリズムのご紹介
最近巷では空前のメニーコアブームで、ふつうのノートPCですら、CPUのコアが
複数あるような時代になっています。そんな時代だからこそ、並列プログラミ
ングというのが重要になってきます。並行プログラミングというと、ロックに
よるデータの排他制御を行う方法が浮かぶのではないでしょうか？ロックによ
る制御では、ロック順序や開放漏れ等注意しなくてはならないことが多く大変
です。
最近では、そのようなロックによる制御ではなく、ロックを使わないロックフ
リーのアルゴリズムによる並行プログラミングが注目を浴びています。今回は、
その中でもソフトウェアトランザクショナルメモリ(STM)というデータ構造を紹
介します。
STMとは、トランザクショナルメモリという名前からも分かるように、トランザ
クション機構を持ったメモリのことです。ソフトウェアという名前は、トラン
ザクショナルメモリが、どう実装されているかを表わしています。ソフトウェ
アがあるからには、当然ハードウェアトランザクショナルメモリ(HTM)も存在し
ています。STMはソフトウェアによるトランザクショナルメモリの実装、HTMは
ハードウェアによるトランザクショナルメモリの実装です。トランザクショナ
ルメモリの実装としては、STMのほうが一般的のようです。
STMを使用したプログラミングでは、トランザクション内では他スレッドのこと
を気にせず、スレッド単位で共有メモリに対してメモリの変更を行なっていき
ます。このとき、トランザクション中のメモリに対する変更は、実際のメモリ
に対して行なわれません。メモリの内容をコピーした領域に対して変更が行わ
れます。プログラマは、このようなメモリの違いを意識せずにプログラミング
をすることができます。
トランザクション内での変更は、STMの機構によって記録されおり、トランザク
ションを終える際に検証されます。検証によって、そのスレッドによる変更が
正しいものとされたときは、コミットされ変更がメモリに反映されます。逆に
不正とみなされた場合は、ロールバックされ最初からやり直されます。
ここまで紹介したようにSTMでは、プログラミングをする側では、スレッドで動
作していることを意識せずに、シングルスレッドのプログラムのように記述が
可能です。スレッド間によるデータの排他制御はSTM側にまかせることができる
ので、処理について集中することができます。
このように便利なSTMも短所はあります。まず、楽観的に処理を進めてから失敗
したらやり直すという方針なので、最悪の場合、並列化しないときと同じ実行
時間がかかる可能性があります。また、I/O処理などがトランザクションに含ま
れているとロールバックができないという問題もあります。これらは、トラン
ザクションの設計の仕方により、ある程度回避が可能です。また、STMは一旦共
有メモリをコピーするという性質上、メモリ使用量が多くなるというのもあり
ます。
ここまで読んでいただいた奇特な方々は、STMを試してみたくなっているのでは
ないでしょうか？自分が扱うことのできる言語でSTMのライブラリを探してみる
のもいいですね。しかし、ここは新しい概念を覚えると同時にSTMを言語レベル
で用意している新しい言語を使ってみませんか？
STMを言語レベルでサポートしている言語として、Clojure( http://clojure.org/ )
という言語があります。ClojureはJVM上で動くLispベースの言語です。JVMで動
作するため既存のJavaのライブラリを呼ぶことも可能です。
実は手前味噌ながら、7月に行なわれたオブジェクト倶楽部夏イベントの若人セ
ッションにおいて、ClojureでのSTMについて簡単に紹介しました。よろしけれ
ば参考にしてください。
http://www.slideshare.net/takkanm/carcons
それでは、みなさんも楽しい並列ライフを！！(m)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┗【PF】現場リーダーの心得 [29]
オブジェクト倶楽部メルマガ読者のみなさん、こんにちは。
岡島です。
遅まきながらiPhoneを手に入れました。出張の多い私にとってはなんとも心強
い味方です。これでやっと、初めて泊まるホテルの場所をノートPCを開いて探
す必要がなくなりましたし、初めての土地で食事の場所を探すのが楽しくなり
ました。
もちろん、メールやスケジュールを、場所を気にせずチェックしたり更新でき
るのも便利ですね。そのせいもあってか、最近はオフィスに立ち寄らず、客先
や新幹線、喫茶店で仕事を続けてしまう自分に気が付きました。「これってあ
まりよいことではないのかもなぁ。」と思いつつ、ついつい便利さに頼ってし
まいます。
傍から見ると、私は忙しい人に見られているかもしれません。
さて今回は、現場リーダーとして、そんな「忙しいお客様」と一緒に仕事を進
める場合のコツと心構えを説明させてください。(ちょっと強引な展開だったか
も・・・)
● 指示されるのではなく提案し主導権を握る
「忙しいお客様」とは、具体的には「複数のプロジェクトを掛け持ちをしてい
るお客様」です。特に小規模なプロジェクトの場合、担当者が専任化されずこ
のような状況になることがよくあります。
掛け持ちをしている場合どうような状況が起きやすいかというと、簡単に言え
ば「言ったことを忘れてしまう」ことが発生しがちです。ただし、お客様も仕
事の目的やイメージを忘れるわけではありませんので、細かい部分のつじつま
が合わなくなって、「言った・言わない問題」が発生しがちになります。
これを防ぐために議事録を書いたりメールにて記録を残すのですが、もっと大
切なことは、「受け身ではなくて提案の姿勢を貫き、主導権をこちら側に持っ
てきてしまうこと」なのです。
これはお客様の立場にとっても悪いことではありません。例えば、「○○とい
う目的に対しては、このようなやり方もあると思います。次回までにはこの部
分を詳しく調査してきます」などといった姿勢で、細かい作業指示を受けるの
ではなく目的や要求を実現するための提案をどんどん打っていきます。
● 議事録は1分で概要が理解できるように書く
もちろん、打ち合わせが行われた場合には議事録はしっかり作成します。詳し
い書き方は以前説明した気がするので割愛しますが、ポイントだけ言えば「忙
しい人が1分で内容を把握できるよう、最初に、目的と結論を明確に書くこと」
これにつきます。結論のでないような会議もありますが、その場合でも、なん
とか目的に対する一応の結論は出せるよう会の進行を導いていく必要があるの
です。その結果、「○○については再検討」でも構いません。
うやむやに終わってしまう打ち合わせは、忙しいお客様にとっては時間の無駄
に過ぎません。くどいようですが、「明確な指示がなかったから」といった言
い訳をしてはいけません。
● 価値と目的追求に重きを置くマネジメント思考で取り組む
ソフトウェア開発を失敗させる大きな原因の一つは「要件がぶれること」です。
いくら変化に対応しやすいといわれる繰り返し型の開発であっても、許容でき
ない変更はあります。
お客様が忙しく要件について細部を合意できないまま進めている場合、終盤に
なって突然「こんなこと言ったっけ？」「イメージと違う」という大どんでん
返しが発生することがあります。私は、お客様の言葉尻だけを追いかけ続ける
とこのようなことが発生しやすいと感じます。
誰しも、忙しく会話や思考に集中できていないときは、理詰めではなく感覚や
雰囲気で進めてしまうことがあるかと思いますが、それはお客様とのやり取り
でも発生します。このような状況で決まった事柄が、後になってひっくり返る
ことが多いのです。そしてそのような状況を生んでしまうのは、お客様だけの
問題ではありません。リーダーには、プロジェクトの目的・価値や解決したい
課題を深く理解し提案的に行動する、マネジメント思考が必要です。「言われ
たことを一字一句間違えずそのままメンバーに伝えて仕上げよう」というワー
カー思考で臨むと、プロジェクトの終盤に大きな「テコ入れ」が発生し、その
対応に苦労することになるのです。
忙しいお客様とのお付き合いで繰り広げられるプロジェクトは確かに大変です。
しかし、細かい部分にまで気を使ってくださる「よいお客様」との仕事では、
なかなか味わえない経験であることも事実です。この苦労は、リーダーとして
社会人として、一人前になるには必要なことなのです。忙しく厳しいお客様に
当たった時には、「これは成長のチャンスだ」と前向きに考え、ステップアッ
プしてください。(岡島)
■ 永和システムマネジメントの組込みソフトウェア開発
ICTとETのクロスーオーバーを目指します。
http://et.esm.co.jp/site/index.html
■「ソフトウェア開発を成功させるチームビルディング」
現場リーダーの仕事術をチームビルディングの観点から説明しています。
http://www.amazon.co.jp/exec/obidos/ASIN/4797352434/xpjp-22
■ okajima_yukioのtwitter
http://twitter.com/okajima_yukio/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人のナガタユウコです。オブジェクト倶楽部では毎年卓上の
カレンダーを作成していることをご存知の方／カレンダーを実際にお持ちの方
も多いと思いますが、2011年のカレンダーもただいま製作中です！スタッフが
一ヶ月毎にネタ出しを担当し、自分の得意分野や興味を持っていることを紹介
しています。卓上にピッタリなハガキサイズで、書き込み欄も大きく取ってあ
るので、仕事にもプライベートにもピッタリなオブラブカレンダー、2011年版
もご期待ください！(ナガタユウコ)
*** オブラブスタッフ自己紹介 ***
No.28 IENAGA
こんにちは、IENAGAです。
IENAGAは、メルマガ作成でオブジェクト倶楽部に関わっています。
(その他には、イベントの時の案内係です。)
過去に扱ったメルマガのテーマは、C#、Ruby、RSpec、jQuery、現在は、XPのコ
ンテキストにおける受入テストです。
最近の連載に関しては、次をご覧ください。
1) /ml-arch/magazine/316.html
2) /ml-arch/magazine/321.html
3) /ml-arch/magazine/325.html
4) /ml-arch/magazine/330.html
5) /ml-arch/magazine/334.html
6) /ml-arch/magazine/338.html
7) /ml-arch/magazine/345.html
8) /ml-arch/magazine/349.html
9) /ml-arch/magazine/355.html
メルマガを書いていると、ときおり、我ながらいい文書が書けたと思えること
があり、ふふーん♪な感じに連載させていただいています。
締め切りは、いつも、期限切れで出しちゃっていますが。
ごめんなさい。編集長。
ではでは。(IENAGA)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒/community/object_ml/help/
〇 免責事項、過去の記事は ⇒/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://ObjectClub.jp/
Copyright (c)2010 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.