実践的オブジェクト指向分析入門26

　この記事は、実践的オブジェクト指向分析入門25の続きです。前回は、オブジェクトモデルの作業のうちの1つである「データ辞書の用意」について解説しました。今回は「クラス間の関係の識別」を解説します。
　殆どのオブジェクトは何らかの関連を持っています。例えば、商品オブジェクトは顧客オブジェクトや会社オブジェクトなどと何らかの関係を持ちます。オブジェクト指向分析の段階で、そういった関係に注目する事は非常に大事です。何故ならば、システムはプログラムだけで成り立つものではなく、ネットワークとデータベースも絡んでくるからです。
　不慣れな分析者は、データベースの概要設計とオブジェクト指向分析を分けてしてしまいます。しかしながら、その様に分けて開発作業を分けてしまうと、問題領域（ドメイン）に関する認識の差異が生じ様々な弊害を生み出します。この原因は、オブジェクト指向とデータ中心アプローチは違うと考え過ぎる点にあります。
　オブジェクト指向分析とデータ中心アプローチが違うのは事実です。ですが、オブジェクトと捉えるのか、実体と捉えるのかは同じ行為です。何故ならば、人間がどのように情報を認識するかというだけの話しだからです。情報を集合に置き変えて考えると、オブジェクトも実体も同じものです。ただし、集合と言っても数学的な集合と同じとは考えないでください。開発メンバー全員で厳密な集合理論を展開するのは無理があります。あくまで集合なようなもの（情報の塊もしくは情報の側面）だと柔軟に考えて下さい。続く...

アジャイル開発を元に考えるプロジェクトマネージャのあり方10

　この記事は、アジャイル開発を元に考えるプロジェクトマネージャのあり方9の続きです。前回は人員の管理について解説しました。今回は開発者の自己管理について解説します。
　ウォターフォール開発モデルなどの従来の開発方法論は、「設計通りに実装しろ」というふうに、上流工程から仕事を振られる形で開発が進められていました。しかし、アジャイル開発はそうではありません。分析や設計と言った行為は行いますが、あらかじめ定められたプロセスを硬直した形で行いません。開発者は短い期間で動くものを求められます。
　アジャイル開発は、チームを重要視する姿勢が目立ちますが、個人もまた重要視されています。何故ならば、アジャイル開発は顧客やチーム間での「信頼」を大事にするからです。個々の開発者が宣言した期間内で目標が達成出来ないと、信頼を失うのは明白です。また、責任感がない人を信頼する人はいません。
　従って、アジャイル開発でのチームの重視は、開発者個人の重視も意味します。さらに、アジャイル開発はプロセスをシンプルにし、作業を細かく分けて開発を進めるので、従来よりも活発に開発作業をせざるを得なくなります。ウォターフォール開発モデルとは違い、短期間で動く／動かないという形で仕事の成否がはっきり出されますので、開発チームは責任を曖昧にし難くなります。チームの責任がはっきりすると、個人もまた責任感を感じざるをえません。
　そういった事から、開発者個人も自己管理を余儀なくされます。以前のように仕事が上流から降ってくるのではなく、主体的に開発作業を進めるアジャイル開発は、プロジェクトマネージャの負担を減らします。従来のように、個人の仕事の細部まで管理する必要はありません。続く...

ネタつつき92－クラウドコンピューティングって何だろう？

　ここ数年クラウドコンピューティングという単語が流行っています。私はこの単語を初めて聞いた時から、極めて古い概念を言い変えただけだと考えていました。というのもクラウドの定義を調べた結果、MULTICSが実現しようとしていたコンピュータユーティリティと同様だとしか思えなかったからです。OSを学習した人は同様の感想を持ったと思います。とはいえ知らない人も多いと思いますので、MULTICSとコンピュータユーティリティについて簡潔に説明します。
　MULTICSというのは、数百人のユーザが1つの巨大マシンを共同利用するためのシステムの事です。このシステムは、電力供給システムをモデルとしており、人々が何時でも好きな時に電力のように簡単にコンピュータを利用できる事を目指していました。この考え方をコンピュータユーティリティと呼びます。
　このアイデアは非常に魅力的で、MIT、ベル研究所、General Electric社（当時の大企業）が共同して開発しました。MULTICSを開発する事により様々なアイデアが生まれ、後のOSにも多大な影響を与えたのですが、PL/Iコンパイラの実装ミス、正確な時間を管理できない等の技術的問題がありました。さらに、その他色々な事があり商売上は成功しませんでした。
　ベル研究所とGE社は開発プロジェクトから外れ、MITだけが開発を続けて一応完成させました。その後、Honeywell社がMULTICSを販売しました。MULTICSは80の主要な企業と大学に納入され、1990年代の後半まで使われ続けたそうです。当初開発に参加した組織にとっては商売上失敗だったと思いますが、総合的に考えると成功だと言えるでしょう。
　コンピュータユーティリティとクラウドコンピューティングが全く同じだとは思いませんが、考え方はかなり昔から続いていると言えます。集中と分散を繰り返し、いずれコンピュータユーティリティが実現するでしょう。そしてその後、集中する事の不利益が発覚して分散に戻るでしょう。人の歴史は繰り返します。
　情報産業では、色々な用語が次から次へと出現し暫く経ったら話題に上がらなくなります。しかし、また用語を変えて復活します。情報処理技術は移り変わりが激しいとよく言われますが、人間が考えている以上その本質は変わりません。これは、クラウドコンピュータに限った話しではありません。あらゆる出来事が繰り返し起こっています。
　技術に新旧があるように見えますが、人間の本質そのものは変わりません。新旧に拘らず、物事の本質をよく見極めて適切な判断をしましょう。クラウドコンピューティングに無視するのも、クラウドコンピューティングに依存するのも間違いです。あらゆる技術は冷静に考察し有効に使いましょう。

ネタつつき91 - 正しい情報の見分け方

　情報化社会を迎え、世の中には情報が溢れています。情報の量が多いのは良い面もありますが悪い面もあります。情報の量が多ければ、それだけ知識の幅が広がり判断材料も増えますが、同時に誤情報や虚偽情報が多くなる事も意味します。従って、情報化社会に生きる我々は正しい情報を見分ける眼が必要になります。
　先に結論を書きますと、自分の頭で考える姿勢と知性を磨く訓練が大事です。そして、常に疑い、常に多くを受け入れるという一見相反する考え方が大事です。この結論は難しいと思いますのでこれから詳しく書きます。
　情報量が爆発的に増え、役に立つ情報が容易に手に入る時代ですから、役に立つ情報を出来るだけ早く、沢山手に入れたいと考える人が多いと思います。しかし、情報は役に立つものばかりではありません。役に立つどころか、誤った情報も沢山あります。その情報の成否を判断するのは非常に難しい事です。
　基本的かつ有名な姿勢は情報源（ソース）がない情報は信じないという考え方です。この考えはある一定の効果をあげますが、完璧な対策方法ではありません。この考え方の利点は、条件が簡単に見え、効果もそれなりだという事です。しかしながら、情報源もまた人間の頭で情報が加工されて出来た情報です。その人の主観が入りますから、情報源だからと言って正しいとは限りません。それに加えて、情報源の情報源はどうやって探すのかという課題もあります。
　人間に限らず全ての生物は何らかの情報処理をしています。五感を通じてこの世で発生する全ての情報を捉え、脳でその情報を処理します。その点に盲点が存在します。全ての情報は加工されてしまうのです。ですから、その人の主観が一切入らない情報はそもそも存在しません。人の考え方は千差万別です。その人にとって正しい情報でも、他の人にとって正しいとは限りません。ですから、ある人が正しいと考えた情報であっても、他の人にとっては間違っているという事がありえます。極論を言えば、全ての正しい情報は自分が体験せねば得られないとさえ感じるでしょう。しかし、体験主義もまた不完全な考え方です。何故ならば、この考え方は自分は正しい事を前提にしていますが、自分が正しいとは限りません。全ての事に於いて正しい完璧な人間はいないというのが唯一の正しい情報だと言えるでしょう。また、一人の人間が体験できる事は高が知れています。
　報源が間違っている事もあり、体験主義も間違う可能性があります。では、何を信じればいいのでしょうか？答えは簡単です。自分を含め何事も信じ切らなければいいのです。
　苦労した結果得た正しい情報であっても、全ての情報には前提となる条件と状況が存在し、その状況は刻一刻と変化します。ですから、正しい情報であっても、長い期間信じ続けるのは非常に危険です。かといって、ある程度信用しなければ物事は前に進みません。従って、ある程度信じて情報を活用しつつ、誤情報である可能性を頭の片隅に置き、全ての物事は多面的で変化しやすいと考えるのがベストだと言えます。
　情報化社会に於いて、情報を食わず嫌いになるのは勿体無いと言えます。しかしながら、何でも食べすぎれば（信じすぎれば）毒となります。毒にも薬にもなる情報の性質を受け入れ、情報化社会を謳歌しましょう。そうすれば、豊かな心と知識を持つ魅力的な人間になれますし、人生も実りあるものとなります。

Win32並行処理プログラミング入門42

　この記事は、Win32並行処理プログラミング入門41の続きです。前回はセマフォの背景知識を解説しました。今回はセマフォ関連のWin32APIとセマフォ・カーネルオブジェクトについて解説します。
　セマフォ・カーネルオブジェクトの特徴がよく表れているのが、Win32並行処理プログラミング入門40に掲載したサンプルの次の部分です。

    //セマフォの初期化と破棄が必要
    ConcurrentFoo() : _number( 0 ) 
    { 
        //最大値を1にするとミューテックスに近くなる
        this->_semaphore = CreateSemaphore( 
            __nullptr, 
            1, //利用可能なリソースの数 
            1, //リソースの最大値
            __nullptr );
    }

このコードはバイナリセマフォを作成しています。バイナリセマフォとは、再帰カウンタが0と1の値しか持たないミューテックスに近いものです。セマフォ・カーネルオブジェクトは、CreateSemaphore関数の引数として「現在利用可能なリソースの数」と「同時にアクセス可能なリソースの最大数」を設定できます。
　セマフォ・カーネルオブジェクトは、有限のリソースを排他制御するのに使用します。同時にアクセス可能なリソースの最大値を設定できるので、サーバのプログラムなどで使用すると便利です。それに加え、CreateSemaphoreには別の使い方があります。

LONG semaphoreCount;
this->_semaphore = CreateSemaphore( 
    __nullptr, 
    0, //利用可能なリソースの数を0にしておく 
    10, //リソースの最大値を適切なものにする
    __nullptr );

//この間でリソースを初期化する

//全てのリソースが使用可能になった！
ReleaseSemaphore( this->_semaphore, 10,  &semaphoreCount );

この様にCreateSemaphore関数で現在利用可能なリソースの数を0に設定すると、セマフォ・カーネルオブジェクトは非シグナル状態になり、初期化していない共有リソースがアクセスされるのを防ぐ事が出来ます。リソースの初期化が終了し、ReleaseSemaphore関数により現在利用可能なリソースの数を増やせば、並行処理されている他のプログラムからアクセス可能となります。なお、ReleaseSemaphore関数の3番目の引数は、それまでのカウントの値です。それまでのカウントの値が必要ない場合はNULL値を指定します。
　並行処理プログラミングでは、複数のプログラムが同時に実行されている事を思い出して下さい。もし、運悪く初期化されていない共有リソースにアクセスされれば処理結果が適切なものなりません。カーネルオブジェクトが非シグナル状態になると、WaitForSingleObject関数は制御を戻しません（タイムアウトは除く）。これにより、適切にWin32APIを使っていれば、この様な事態を避ける事が出来ます。もちろん、WaitForSingleObject関数が使用されていなければアクセス出来てしまいますが、それは根本的に間違っています。続く...

実践的オブジェクト指向分析入門25

　この記事は、実践的オブジェクト指向分析入門24の続きです。前回は、ブジェクトモデルの作業の内の1つである「オブジェクトおよびクラスの識別」について解説しました。今回は、オブジェクトモデルの作業のうちの1つである「データ辞書の用意」について解説します。
　問題領域（ドメイン）にあるオブジェクトになりうる単語もしくは、重要な概念についてデータ辞書を用意する必要があります。その理由は、開発メンバー間で情報を共有し、解釈の差異によりプロジェクトが混乱しないようにするためです。
　プロジェクトが失敗する原因は色々ありますが、そのうちの1つが情報の共有を疎かにする事です。人によりオブジェクトもしくは用語の解釈に違いがあれば、色々な場面で不都合が生じプロジェクトは失敗します。開発者ごとにオブジェクトの捉え方が違えば、処理内容に違いが生じてしまいます。また、余計な論争が起こるなど生産性を低下させる現象も起こります。
　プロジェクトの開始からシステムの破棄まで常に同じメンバーが開発に携わり、その開発メンバーの連携が完璧であれば、データ辞書は必要ないと思われるかもしれません。ですが、実際はそのシステムに関わる人材はよく変わります。
　メンバーが変わるたびに、口頭でオブジェクトや用語の定義を伝えるのは、非常に大変かつ間違いが生じやすい行為です。始めは面倒だと思うでしょうが、あらかじめデータ辞書を用意しておけば後の労力が非常に軽減されます。続く...

Win32並行処理プログラミング入門41

　この記事は、Win32並行処理プログラミング入門40の続きです。前回はセマフォ・カーネルオブジェクトを解説しました。今回も引き続き、セマフォ・カーネルオブジェクトについて解説します。
　先ずはセマフォの概念を解説します。セマフォは1945年にE.W.Dikstra氏が提案したもので、シグナルの紛失問題を解決し、プロセス間で共有するリソース／コードを排他制御するためのものです。
　シグナル紛失問題は難しい概念なので例を挙げて解説します。仮にリソースを共有するスレッドが2つあるとします。この2つのスレッドは、片方が共有リソースにオブジェクトを格納し、片方が共有リソースからオブジェクトを取りだします。この場合、オブジェクトを消費するスレッドは、共有リソースがなければ何もできないのでスリープしなくてはなりません。一方、共有リソースにオブジェクトを格納するスレッドは、共有リソースに格納する時オブジェクトの数が0個であれば、スリープしているであろうスレッドを起こさなくてはなりません。しかし、この状況で並行処理特有の問題が起こる可能性があります。
　オブジェクトを消費するスレッドが活動した結果、共有リソースに格納されているオブジェクトの数が0個になり、スリープする前にオブジェクトを格納するスレッドが処理をすれば問題がおきます。何故ならば、オブジェクトを消費するスレッドはまだスリープしていないからです。この時、スリープを指示するシグナルは紛失してしまいます。
　このシグナル紛失問題を解決するには、スレッド間でチェックする変数を共有し、その共有した変数をアトミックに加算／減算する方法があります。互いにチェックする共有変巣があれば、スリープしなくてはならないタイミングが分かりますので問題は解決します。
　Windowsのセマフォ・カーネルオブジェクトはこの考えに基づき作られています。その特徴は、ミューテックス・カーネルオブジェクト同様プロセス間でリソースもしくはコード片を共有できる上に、リソースの最大数を設定できる事です。続く...

.NET Frameworkとは何か？

　.NET Frameworkという用語は開発者の間で有名だと思います。しかしながら、有名になった分誤解もまた広く広がっていると思いましたので改めて解説をする事にしました。.NET Frameworkの真の姿をとらえるべく、正しく用語を理解しましょう。
　.NET Frameworkが何を意味するのか知るためには、先ず.NET Frameworkが誕生する前の状態を知る必要があります。.NET Frameworkが誕生する前は、様々な技術と開発環境が混在していました。C言語を使って、Win32APIを駆使してプログラミングをする方法。C++言語を使って、MFCでプログラミングする方法。VB言語を使って、独自の開発環境でプログラミングする方法。COM（ Componet Object Model ）を使用して、C++もしくはVBでプログラミングする方法。JavaScriptもしくはVBScript言語でWindows DNAを使用し、Webアプリケーションをプログラミングする方法...などです。
　これらの方法は全て実績があり、今もなお使用され続けていますが、同じWindowsプログラミングなのにも関わらず、様々な事柄を覚えなければならないという深刻な問題がありました。Windowsプログラミングを統一した方法で行いたいという要望が高まりました。その結果生まれたのが、COMを発展させた.NET Frameworkです。
　従来の方法は、プログラミング方法がプログラミング言語に依存していました。COMではその制限が緩和されましたが、配置や表現方法の不統一などの問題がありました。.NET Frameworkは共通言語ランタイム（ CLR : Common Language Runtime ）により、プログラム言語に依存せず、統一した方法でプログラミングが出来るようになりました。
　誤解されやすいのですが、.NET Frameworkはただのクラスライブラリではありません。それは.NETの1つの側面でFCL（ Framework Class Library )です。.NET Frameworkは、Frameworkの名が示す通り、配置・WPF・Windows Form・WCF・WF・ADO.NET・ASP.NET・属性プログラミング・並列処理...など様々な技術的な仕組みを提供しています。
　.NET Frameworkは様々な側面を持つ、非常に複雑なフレームワークです。ただのクラスライブラリと捉えると、その本質を見失います。.NET Frameworkを多面的にとらえ、様々な技術を楽しみましょう♪

アジャイル開発を元に考えるプロジェクトマネージャのあり方9

　この記事は、アジャイル開発を元に考えるプロジェクトマネージャのあり方8の続きです。前回は、変化に対し迅速かつ柔軟に対応するべく、システム開発の情報を管理する方法を解説しました。今回は人員の管理について解説します。
　前回述べたように、変化が速く迅速な対応を求められる昨今では、システム開発で発生する情報は莫大なものになります。莫大な情報に対処するには、業務として行う情報を分析と管理をしなければなりません。しかしながら、プロジェクトマネージャも人間であり、どんな優秀な人でも限界があります。ですから、情報がそもそも発生しないようにする必要があります。
　優秀なプロジェクトマネージャによくある失敗は、自分で全ての仕事を捌こうとする事です。責任を持つプロジェクトマネージャからしてみれば、部下に仕事を任せるのは不安で仕方がないのでしょう。その気持ちは理解できます。しかしながら、人員の育成も立派な仕事ですし、優秀なプロジェクトマネージャはより高度な仕事に集中しなくてはなりません。従って、部下に自己マネージメントをさせるのがベストです。
　マネージメントという言葉は、日本では支配者という意味合いでよく使われます。しかし、本来はその様な狭い範囲の言葉ではなく、マネージメントは人間が日常的に行っている事も含まれています。ですから、マネージメントはやろうと思えば誰でも出来る事です。にわかには信じられないと思いますので、例を挙げて日常的なマネージメントを解説します。
　社会人になると多くの人が、スキルを高めるべく日夜学習をしています。学習をする際、目標を立てて鍛練をします。目標を立て、それに向かって行為をするのですからこれも立派なマネージメントです。また、誰しも自分の生活を考え、時間を管理しているはずです。これもまたマネージメントです。
　この例を読んだ人の中には、システム開発での管理と違う話しだと思う人もいるでしょうが、アジャイル開発は自己管理も重要視されます。ですから、自己管理を強く推奨できる環境が既にあります。続く...

Win32並行処理プログラミング入門40

　この記事は、Win32並行処理プログラミング入門39の続きです。前回はミューテックス・カーネルオブジェクトを解説しました。今回はセマフォ・カーネルオブジェクトを解説します。
　今まで数個の同期オブジェクトを解説してきましたが、まだ解説するべき同期オブジェクトが残っています。それが今回解説を始める、セマフォ・カーネルオブジェクトです。
　分かりやすいように、ミューテックス・カーネルオブジェクトと同じ内容のサンプルを使用して解説を行います。

#include <iostream>
#include <windows.h>
#include <tchar.h>
#include <process.h>
using namespace std;

//インスタンスのポインタとパラメータを保持するクラス
class InstanceAndParameter
{
private:
    void* ins;
    void* param;
public:
    InstanceAndParameter( void* ins, void* param ) 
        : ins( ins ), param( param ){}
    void* getInstance() const { return ins; } 
    void* getParameter() const { return param; }
};

//並行処理を意識したクラス
class ConcurrentFoo 
{
private:
    HANDLE _semaphore;
    long _number;
public:
    //セマフォの初期化と破棄が必要
    ConcurrentFoo() : _number( 0 ) 
    { 
        //最大値を1にするとミューテックスに近くなる
        this->_semaphore = CreateSemaphore( 
            __nullptr, 
            1, //利用可能なリソースの数 
            1, //リソースの最大値
            __nullptr );
    }
    ~ConcurrentFoo()
    { 
        CloseHandle( this->_semaphore );
    }
    long getNumber() const { return _number; }

    //並列的に実行するメソッド
    //※並行度は高いが遅い
    void AddFunc( int count )
    {
        LONG semaphoreCount;
        for ( int i = 0; i < count; i++ ) {
            WaitForSingleObject( this->_semaphore, INFINITE );
            ++this->_number;
            ReleaseSemaphore( this->_semaphore, 1,  &semaphoreCount );
        }
    }

    //スレッドから呼び出すメソッド
    static unsigned __stdcall Add( void* pvParam ) 
    {
        //パラメータのチェック
        _ASSERTE( FALSE == IsBadReadPtr( pvParam, 
            sizeof( InstanceAndParameter ) ) 
            && "スレッドに渡されたパラメータが無効です" ); 

        //インスタンスとパラメータを取り出してメソッドを実行
        InstanceAndParameter* ip = 
            reinterpret_cast< InstanceAndParameter* >( pvParam );
        ConcurrentFoo* obj = 
            reinterpret_cast< ConcurrentFoo* >( ip->getInstance() );
        int count = PtrToInt( 
            reinterpret_cast< INT_PTR >( ip->getParameter() ) );
        obj->AddFunc( count );
        return 0;
    }
};

int _tmain( int, _TCHAR* )
{
    //スレッド数の判定
    const int threadCount = 64;
    if ( threadCount > MAXIMUM_WAIT_OBJECTS ) {
        cout << "【エラー】" << endl;
        cout << "指定するスレッド数が多すぎます。" << endl;
        cout << "指定するスレッド数は" 
            << MAXIMUM_WAIT_OBJECTS 
            << "以下にして下さい。" << endl;
        return -1;
    }

    //スレッドのパラメータを用意する
    ConcurrentFoo obj;
    int count = 100000;
    InstanceAndParameter threadparam( 
        reinterpret_cast< void * >( &obj ), 
        reinterpret_cast< void * >( ( INT_PTR ) count ) );

    //スレッドを作成する
    HANDLE hThreads[ threadCount ];
    for ( int i = 0; i < threadCount; i++ )
    {
        hThreads[ i ] = reinterpret_cast< HANDLE >( 
            _beginthreadex ( 
                __nullptr,
                0U,
                ConcurrentFoo::Add,
                reinterpret_cast< void * >( &threadparam ) ,
                CREATE_SUSPENDED, //直ぐには実行しない
                __nullptr ) );
    }

    //作成したスレッドを実行
    for ( int i = 0; i < threadCount; i++) 
        ResumeThread( hThreads[ i ] );

    //タイムアウト時間をミリ単位で指定して待機
    //※指定した時間は正確ではありません
    DWORD result = WaitForMultipleObjects( 
        threadCount, hThreads, TRUE, 20000 );

    //WaitForSingleObject関数が終了した原因を表示
    cout << "【スレッドの状態を表示します】" << endl;
    unsigned int max = ( WAIT_OBJECT_0 + threadCount - 1 );
    if ( result == WAIT_FAILED ) { 
        //エラーを表示する
        DWORD error = GetLastError();
        LPVOID title = _T( "エラー" );
        LPVOID msg;
        FormatMessage( FORMAT_MESSAGE_ALLOCATE_BUFFER |
                FORMAT_MESSAGE_FROM_SYSTEM |
                FORMAT_MESSAGE_IGNORE_INSERTS,
            __nullptr,
            GetLastError(),
            MAKELANGID( LANG_NEUTRAL, SUBLANG_DEFAULT ), // 既定の言語
            reinterpret_cast< LPTSTR >( &msg ),
            0,
            __nullptr
        );
        MessageBox( __nullptr, 
            reinterpret_cast< LPCTSTR >( msg ) , 
            reinterpret_cast< LPCTSTR >( title ), 
            MB_OK | MB_ICONERROR );
        LocalFree( msg );
        return -1;
    } 
    if ( result == WAIT_TIMEOUT ) {
        cout << "タイムアウトしてしまいました。" << endl;
    } else if ( ( result >= WAIT_OBJECT_0 ) & ( result <= max ) ) {
        cout << "全スレッドの処理が終わりました。" << endl;
    } 
    cout << endl;

    //変数の合計値を表示
    long correctValue = threadCount * count;
    long number = obj.getNumber();
    cout << "【変数の値を表示します】" << endl;
    cout << "予想値：" << correctValue << endl;  
    cout << "実際の値：" << number << endl;
    cout << "不足値：" << ( correctValue - number ) << endl;

    //ハンドルを閉じる
    for ( int i = 0; i < threadCount; i++ ) 
        CloseHandle( hThreads[ i ] );
    cout << endl;
    return 0;
}

このサンプルは、ミューテックス・カーネルオブジェクトの解説時に使用したものと同じ内容です。違う部分はConcurrentFoo クラスだけです。同期オブジェクトの隠蔽を行うと、この様に変更に強いオブジェクトが作れます。
　長くなりましたので、セマフォ・カーネルオブジェクトの詳しい解説は次回から行います。