| ◆ マイクロカーネル ( マークMach & RT-Mach ) 関係のページ | |||||||||
|
◆ 他のホームページは Google で検索して下さい、弊社のページはそれぞれのボタン、又はリンク先をクリックして下さい。 ◆ マイクロ・カーネル・アーキテクチャ ◆ リンクページ ◆ 弊社の製品一覧 ◆ 他リンクページ ◆ リスクファィブ（RISC-V）関係 ◆ 自動制御システム構築や制御ネットワーク構築などで困っておられましたら是非とも弊社にご連絡下さればご相談は無料で受け付けております。
E-Mail :こちらをクリックして下さい。 ◆ 弊社では、自動制御システムのハードとソフト関係で約32年の経験があります。 ◆ このページについて皆様からのご意見、或いはご要望などがありましたら、是非下記へメールでご連絡下さい。
|
|||||||||
|
▼ Zircon新マイクロカーネル 2020.07.26 Google社では、Androidから移行する新OSのFuchsia用の新マイクロ・カーネル Zircon Kernelを開発していた。 ▼ マイクロカーネルMach '02.10.15 近年、リアルタイムOSの重要性が取り挙げれており、Real Time Mach ( RT-Mach )やReal Time Linux ( RT-Linux )などがあり制御関係のOSでは、リアルタイム性が最も重要であり、NASAで打ち上げたロケットが火星で制御不能となる事故が発生したことは有名でしょう、その原因はソフトウェアのバグと報じられておりますが、OSのタスクの優先順位度が逆転したのではないかとも言われており、某OA用のWindowsなるOSも同様なことが発生します、これに腹をたてた人たちはPCを叩いたりしていることもしばしば見受けられます。 制御関係ではタスク管理のスケジューリングが大変重要であり、上記のような事情が発生してはならないのです、そのようなOSを利用することはできないでしょう。制御関係の場合には事故が発生した際の損害が非常に高額となるからです。 MacOS Xでも採用されているMachは下記のとおりオブジェクト指向のマイクロ・カーネルをベースとしており、NeXTstepではその安定性が実証されました。
カーネル関係はMachとBSD関連となっており、 Cocoa環境のカーネル構成では、 MacOS X / Mach 3.0のスケジューリング・ポリシーと優先順位は、標準ポリシー( システム定義の公正なスケジューリング ) や時間制約ポリシー( リアルタイム性に従ってスケジューリング ) , 優先順位ポリシー( 他のスレッドより最優先 ) となっており、リアルタイムにも対応しています。 MacOS XではパーソナルなPCでUnixを利用できて、且つ優れたアプリケーションのAdode社のPhotoshop, Illustrator, InDesignや様々な一般的なMacのアプリケーションをUnix上で利用できることは大変意味のあることであると言えます。 Machでのタスクは資源割り当てのための単位であり、資源にはポートネーム空間, 仮想メモリ空間, タスク環境パラメータなどがあります、タスクは複数のスレッドを持つことができる、他のUNIXのプロセスはひとつのスレッドを持つタスクと言われております。 スレッドはプロセッサのステータスやスケジューリングパラメータ、スレッドパラメータの持ちます、スレッドが必要とするレジスタ・パラメータ（ CPUプログラム・カウンタとスタックポインタ ）や優先順位パラメータ、スレッドの記憶領域パラメータなどを持つことになります。 Machでのタスク生成のオーバーベッドはUNIXプロセスの生成オーバーヘッドと同程度と言われており、Machのスケジューリング単位はスレッドであり、そのスレッドは別々のプロセッサーで動作させることも可能です。 MachでのスレッドはC-Threads ( ユーザレベル )と呼ばれる Pthreads ( POSIX スレッド )、及びMach Threads ( カーネルスレッド )があり、Cスレッドであればプログラミングも容易となります、MacOS XではPOSIXスレッドで記述されたプログラムはマルチプロセッサーに対応しています。 システムコールは殆どメッセージ・パッシングとしてのMachメッセージベースで実現され、殆どの操作はメッセージベースでやり取りするオブジェクト指向なOSです、Machは32個のCPUまでのマルチプロセッサに対応しており、その際のCPU間のスレッドの同期を取ったりするためにMachメッセージを使用します。 ◆ WindowsNT / 2000のカーネル '03.07.30 WindowsNT / 2000のカーネルはマイクロカーネルとよく言われていますが、実際にはマイクロカーネルではなく、NT 3.5カーネルでは、パフォーマンスが低く不評であったためパフォーマンスを上げざるを得なくなりNT 4.0以降のカーネルでは必要最低限のカーネル機能以外の機能を統合した巨大化したカーネルサイズであり、モジュール化と階層化のカーネルとなっているのです。 Windows2000のカーネル NT 5.0 は、巨大化したカーネルをモジュール化し、動的にサービス機能を読み込むと言う苦肉の策の機能を追加した、又カーネルも徐々にマルチスレッド化されマウスの反応などの良くするよう改善されたようです。しかし、堅牢性では、Unix系のサーバと比較するとWindows2000サーバは疑問視されています・・・。 '02.08.05 Windows2000カーネルのスレッド・スケジューリングはスレッドの優先度 ( プライオリティ: Priority ) と分量 ( クォンタム:Quantum ) とでCPU時間に割り当てる方式の抽象的なスレッド・スケジューリング方式です、Machのようなプロセッサ・セット機能がないので、リアルタイム性がありません。 Windows2000のカーネルでマルチプロセッサに対応しているのは、Windows2000 Pro.版がDual-CPUまでであり、高価なWindows2000 Datacenter Server版が32個のSMP対応となっています、しかし32個のSMPマシンでの実績があるのでしょうか・・・。 Windows2000のシステム・パフォーマンスでスレッド数を確認できます、アプリ・ソフトを起動させないで、スレッド数は246程度ですが、ブラウザのExplorerを起動するスレッド数がわずか14程度増えるだけです、他のファイル検索やワードパットでもスレッド数が増えるのはわずか2〜6程度です、マルチスレッドと言えるのでしょうか・・・?、不思議です・・・。 Dual-CPUのPCでのWindows2000上でマルチ・プロセッサ対応のソフトを稼動させた場合の性能向上はわずか1.3〜1.5倍程度です、マルチスレッドとマルチプロセッサとの最適化されていないようです・・・、Dual-CPUのPCでのBeOSやMach 3.0では、1.6〜1.8倍の性能向上となります。 ◆ Windows2000のマルチスレッド・プログラミング '03.07.30 MicroSoft社の新技術の開発関係者には創造性がないのでしょうか・・・、Windows2000では、Machのマルチスレッド技術を模倣しマルチスレッド化されつつありますので、アプリケーション側でもマルチスレッド・プログラミングが可能です、しかし、簡単にマルチスレッドなプログラムを製作できる訳でなく、排他制御の設計をしなければならず、１つのプロセス内の複数のスレッドで、或いは他の複数のスレッドの排他制御としてのスレッドのロックとロック解除のタイミングが複雑となるデメリットがあることです、つまり排他制御のバグはデッドロック現象に至りそのプログラムから永遠に抜け出せないことになります。 Windows2000では、Machのようなオブジェクト指向なスレッド間のメッセージ・パッシングとしてのメッセージ通信機能がありません、その代替え機能として共有メモリ ( キュー? 、スタックメモリ機能 ? ) とメールBoxを利用しデータの受け渡しによりプログラミングします、又メモリマップド・ファイルを利用する必要もあるでしょう・・・。 Windows2000のマルチスレッド・プログラミングはそれぞれのライブラリーを利用しC / C++, VC++, C++Builderで行うことが可能です、排他制御用APIには、クリティカルセクション、ミューテックス、セマフォがあり、プロセス内、或いはプロセス外でのスレッドのロックとロック解除を行いイベント処理と複雑で難解なマルチスレッド・プログラミングを行う必要があります。 マルチタスクとマルチプロセス、マルチスレッドの区別がつかない素人プログラマーに、この複雑で難解な排他制御の設計ができるのでしょうか・・・、排他制御のプログラムのバグはパフォーマンス低下や他のプログラムに影響し最悪の場合にはフリーズやハングアップに至ります、Windows2000以降では排他制御バグが大変多くなりデッドロックに至っています、相変わらずの不安定なOSと言うイメージがあります・・・。 ◆ Windows2000の不明確なスレッド優先度設定 ? '03.07.30 Windows2000サーバ版のみ ? には、System PropertiesでのPerformance設定としてQuantum Type & Length設定ではFixed / Variable とShort / Longで固定と可変選択ができるようになっていますが、PC用のプレインストール版などのWindows2000には見当たりません。 スレッド優先度設定では、Quantum TypeとLengthを設定のためのQuantum TableとQuantum Control Valueの設定用Quantum Controlテーブルから参照しスレッドの優先度を決定しているはずであるが、サーバ版以外のWindows2000では、QuantumのTypeとLength選択ができませんので、カーネルでスレッドのスケジューリングができるはずがありません、不思議でなりません・・・。 Windows関係がオープンソースでないため、一般方々やソフトベンダーの方々でさえもカーネルなどの内部の技術に詳しい方はいないのでしょう・・・、マルチスレッド・プログラミングではスレッドのロックとロック解除が必要であり、そのタイミング処理設計が重要となります、MicroSoftの技術資料とカーネル動作を予想しプログラミングしなければならないのでしょう、事実、Windows2000以降デッドロックによるシステムのフリーズやハングアップの問題が多発しており、このようなWindows2000などが堅牢なOSだとか、安定したOSなどとなぜ言えるのでしょうか・・・。 WindowsNT / 2000のカーネルはNTインタラプトの要因や他の要因によりオーバーヘッドの変化が著しくスレッド・スケジューリングにバラツキが発生し、最悪な場合にはブルースクリーン( ハングアップによる画面が青い色に表示する現象 )に陥ります、つまりリアルタイム性がないと言われております。そもそもWindowsNT / 2000はOA関係向けに開発されたOSであるためリアルタイム性は必要ない訳です。 Windows2000のカーネルでのスレッドの優先度設定は抽象的なスケジューリング方式によるアイドル・通常・優先・リアルタイムなどの4つプロセス優先クラスとスレッド相対優先度 ( 1〜31設定 )で行えるようになっています、実際はに、リアルタイム優先の数ミリ秒の設定でも設定目標値の約10倍のバラツキが発生し残念ながらリアルタイムと言えません。 WindowsNT / 2000のカーネルにはリアルタイム性がないため、そのリアルタイム性を補うRT-OSのサードパーティ製ソフトやROM-Windowsなるソフトが市販されています、そのRT-OSはWindowsNT / 2000のカーネルを乗っ取りあたかもWindowsNT / 2000のカーネルのように振る舞うのです、つまり強引な処理の方法でありスレッドの優先度をRT-OS側がコントロールすると言う訳です。 このRT-OSは利用分野は限られるでしょう、高速なデータロギングなどをPC上で安価に構築する場合には利用できるのかもしれません、しかしこのようなシステムの場合PCで実現しなくてもそのような高速なA/Dコンバータと高速なCPUを搭載したBoardが市販されていますので、そのボード用RT-OSを利用しGbitイーサネットなどでPCと接続すれば難しくないと思います。 WindowsNT / 2000用RT-OSはPCにDual-ProcessorのCPUを実装していても、Single-CPUのみの動作でありマルチスレッド対応でないのでしょう・・・、又Machのようにオープンソースでないためライセンス料を要します、Windows関係はクローズドな世界であり、米MicroSoft社は未だにOSのオープンに踏み切れないのです。他のメーカではOSをオープンソースとする傾向にあり非常に残念なことです。 Linux用のLindowsと言うWindowsエミュレータソフトが話題となりました、Windowsのソフトを稼動させるようになっており、技術的には困難ではなくWindowsのカーネルやコア・サービス, APIs関係をエミュレートすれば良い訳であり、国内でも開発する意欲のある方々と投資する方々がおれば実現が可能でしょう・・・。 Windows / PCのハードウェアをエミュレートするLinux用のVMware, Wine, BochsやMacOS用のVirtualPC, SoftWindowsなど数種類存在します、CPUが高性能となったことによりMacOS用のVirtualPCや SoftWindowsは実用的になりました。 Windows / PC関係でもWindowsNT / 2000のカーネル ( Kernel )や Executive Services , APIsなどをEmulateすればWindows自体必要がなくなり、本当の意味でのWin32 Emulator Softになるのです。'03.08.08 当然、オープンソースとして開発者やユーザで運用テストを行い、皆で育てながら完成させることことが大事であり、一大企業の暴利とならないよう、且つバグフィックスを徹底的に行い本当の意味での良質なWin32 Emulator Softとすることが必須であると思います。 MachにはOS Emulator機能があるため、Win32 Emulator SoftをMach 3.0やGNUMach上で稼動されば堅牢性や安定性でも格段に良くなる訳であり、Mach 3.0やGNUMachが稼動するPCが多く実用的となるでしょう・・・。'03.08.08 フリーソフトのCloneと言うWindowsNTをエミュレートするOS ? (react OS)が存在します、どの程度互換性があるのかは不明です。 Linuxでも、Mach 3.0上でLinuxを稼動可能です、Old Mac ( PowerPC 603 & 604 )やMac互換マシンでMKLinuxを利用できます、最近、MKLinuxの開発は活発でなくなりましたが、カーネル関係のプログラミングに自信がある方は最新PowerMac G4やx86系PCへの移植をトライされてみてはいかがでしょうか・・・、MacOS X内Mach 3.0のDarwinがオープンソースとなっていますので、その必要性もないかもしれません・・・。 '03.08.08 ◆ このページに情報を掲示されたい方はどうぞお気軽にご連絡下さい、無料で掲示致します。又ご希望があれば御社、貴殿のページへリンク致します。 このページへはご自由にリンクして下さい、その際Ｅメールでご感想などをご連絡戴ければと思います。
|
▼ Machはご存じのとおりカーネギーメロン大学( CMU )で1985年に研究開発が進められ、当時のUNIXではマルチ・プロセッサーマシンで効率よく利用できない問題点を解決することが目標であったようです。 マルチスレッド・マルチプロセッサの元祖はMachであり、近年、Machを模倣しWindows2000でもマルチスレッド技術が取り入れられており、そのマルチスレッド技術はMachと同等でなく、マルチスレッドを応用したソフトでのデッドロック ( Dead Lock ) 問題のバグが増えております。 MacOS X 10.2ではMach 3.0が採用され、そのマルチスレッド技術とMach 3.0のカーネル機能によりマルチスレッドなマイクロカーネルMach 3.0とマルチスレッドなアプリケーションがDual-CPU ( PowerPC G4 x 2 )マルチ・プロセッサー上で効率良く稼動しています。 ◆ オブジェクト指向なOS ◆ マルチスレッド・マルチプロセッサー対応 ◆ リアルタイム対応 ◆ BSDエミュレーション ( FreeBSD 、及び BSD UNIXと互換性あり) ◆ 複数のOSを稼動させることが可能( MacOS Xでは、BSD4.4とMacOSエミュレータの並列動作可能 ? ) ◆ 他のUNIXと同様に強力な通信機能 ◆ 分散処理や仮想記憶など・・・ マイクロ・カーネル・アーキテクチャとは、OSの最小限の本質的な抽象化された機能のみを実装しファイルシステムやネットワーク処理などを分離したカーネルであり、モノリシックカーネルは分離されていない、モノリシックカーネルはLinuxや4.4BSD / Unix などがあります。 マイクロ・カーネルの利点はマイクロ・カーネル上で複数のOSを同時に実行できること、メッセージ・パッシング対応であること、リアルタイム機能をサポートすることが容易であること、更にOSの拡張性や保守性が優れていること、OS全体の移植が容易である。 Mach 3.0には、プロセス通信としての IPC ( Inter Process Communication ) のポートとメッセージ機能があり、カーネルにより管理と保護されるメッセージ・キューのような機能となっている、このポートとメッセージはタスク間、或いはタスクとカーネル間でメッセージ通信させて、カーネルとタスクのモジュール性を高めています。 マイクロ・カーネルを採用し実用化されたOS はMacOS X とBeOS, NeXTstep, Sun3&4, VAX, DEC Alpha, Luna88Kなどが有名です。 BeOSのカーネルは現存するカーネルでは最も進化したオブジェクト指向でありマルチスレッド化されたカーネルでしょう・・・、先進的なマイクロ・カーネルのスレッド・スケジューラとマルチスレッドの効果は絶大でした、BeOS搭載のPowerPC 604 / 120MHz搭載のPowerMacやBeBOX PowerPC 603 / 66Mhz程度マルチCPU x2個 でも反応の良さは当時の他のPC用Windows95と比較しても反応のよさやWindowに動画を表示したままで動画が停止することなくドラックできたことなど格段に優れていました。 マイクロ・カーネルのサイズがどの程度でマイクロカーネルと言うかなど定義はありません、BeOS ( PPC 版 ) のカーネルはわずか500Kbytes程度です、MKLinuxのMachでは約1Mbytes、MacOS XのMach 3.0カーネルでは3.5Mbytesです。 Windows2000のカーネルは、俗に言うExecutiveコンポーネットの中には、カーネル、システムサービス、オブジェクマネージャー、プロセスマネージャー、メモリマネージャー、HAL、デバイスドライバー、他がコンポーネットとなっています。 Windows2000には、カーネルらしきファイルNTOSKRL 約1.7MB, Win32k.sys約1.7MB , NTKRNPA 約1.7MB , KERNEL32.DLL 約0.9MB, 及び起動用のntoskrnl.exeが存在しますが、これはシステム起動時の初期設定用と思われます、予想では、稼動状態でのプロセスを確認するとmstask.exe / 約3MB, taskmgr / 約3MB, sevices.exe / 約15MB, System.exe / 0.24MBなどであり、タスク関係はカーネルであるからサービス関係を除いてもカーネルサイズ合計6.2MB程度以上になるでしょう、又カーネルメモリの表示では20MB程度となっています・・・。 Windows2000では、メインメモリが256MB以上でないとパフォーマンスが落ちます、カーネルとシステム関係が巨大化していることが原因でしょう・・・、互換性維持の為その稼動マシンでの不必要なオブジェクト・コードが増える一方なのでしょう・・・、巨大化したレジストリによるシステムのコンフィギュレーションの限界か・・・、俗に言う巨大サイズ化で複雑なOSです。 ▼ Real Time Mach ( RT-Mach ) について RT-Mach 又は RT-Mach 3.0とは、Mach-3.0のマイクロ・カーネルに実時間駆動型スケジューラのReal Time機能や資源予約機能などを追加しリアルタイム・スケジューラによる同期制御機能を実現しています、これによって優先度逆転現象を防止することが可能と思われます。 RT-Machにはスケジューリングの検証Toolsやアプリケーション実行中リアルタイム・イベントを収集とタイミングを検証するARM Toolなどが付属しているようです。 Real-Time Machのリアルタイム・ライブラリーはMach 3.0に統合されており、libmachをlibmach_rtに置き換えてリアルタイム・スレッドでソース・コーディングしコンパイルすればよいでしょう・・・。 ライセンス・フリーなLitesとRTSはPC / AT互換機種に移植されており、国内のMKngプロジェクトではi386以上のPC / AT互換機種やPowerPC ( PPC 603,604 ) で稼動可能?です、AppleのPowerBook / 2400で稼動可能 ? ・・・、古い機種のほうが動く可能性が高いようですので、是非とも試してみていかがでしょうか。 Mach 3.0にRT-Machが統合されるいるはずであり、Darwinにもプロセッサ・セットProcessor_set_* () が存在します、Apple ComputerのMacOS X資料にもReal-Time Services関連あります。 Machには、MachのヘッダファイルやMachライブラリ, Cスレッド関係のヘッダファイル,Cスレッドライブラリなどをgccでの開発環境が整っており、そのMachのプログラミングが可能となっています、Cスレッド関係をアプリケーションからコールすればMachのカーネルスレッドを操作することにより細かなプログラムのコーディングも可能でしょう。 スレッド関連のカーネルインターフェースは、Thread_* ()でスレッド生成、スレッドのロックとロック解除、スレッドのプロセッサへの割り当てなどのプログラミングができます。 Mach 3.0のC-ThreadsはP-Threads ( POSIX スレッド ) と同等なユーザレベルのスレッドであり、MacOS X のMach 3.0でもBSD POSIX Pthreads APIを採用しています。 Mach 3.0では、スケジューリングとしてプロセッサの優先度をプロセッサ毎に別々に設定が可能です、１つのプロセッサには固定的な優先度を設定によるリアルタイムとし、２つ目プロセッサには通常のスケジューリングの優先度を設定できるプロセッサ・セットの機能があります。 プロセッサ毎にスケージュリングポリシーのON / OFFやプロセッサの制御パラメータをprocessor_set_* ()のカーネルインターフェースでプログラミングが可能です。 Machには、プロセス通信としての IPC ( Inter Process Communication ) のポートとメッセージ機能があり、Machはメッセージ・ベースのOSであるためスレッドとカーネル、或いはスレッド間との操作やデータの受け渡しはポート・ポートセット・メッセージを利用しプログラミングします。 ポートとメッセージ関連のカーネルインターフェースは、mach_port_* () でポート生成、ポートのカウンターの解除やポート破棄、ポートright、ポートセット移動など、メッセージの送受信は mach_msg () でプログラミングが可能です。 他のタスク関連や仮想記憶関連、メモリオブジェク関連などもありますので、別のMachプログラミング資料やサイトなどを参照下さい。 ◆ MacOS Xでのリアルタイム・アプリ・・・ '03.07.07 Mach-3.0にはReal-Time Machが統合されているようですので、MacOS XのMach 3.0でもリアルタイム性が実現されており、Mach 3.0の機能としてReal-Time Servicesをサポートしているため、プロセッサ・セット機能とReal-Time Threadsを使用しマルチスレッド・プログラミングすれば反応の良いリアルタイム・アプリケーションを製作できるでしょう・・・。 Cocoaで開発環境としてObjective-CでのNSThread classでは、マルチスレッド関係のスレッド通信やスレッド優先度設定+setThreadPriority、条件付きロックNSConditionLock Class, NSLock class, 再帰的なロックNSRecursiveLock Class, 分配型ロックNSDistributedLock ClassでのスレッドのロックLockやロック解除unLock, トライロックtryLockなどのスレッド・プログラミングが可能です。 Mach-4の研究バージョンの開発が進行しています、CMUのMach-3を再編成したカーネルはCPU / x86とCPU / PA-RISCのみようであり、PowerPCなどのCPUには対応していないようです、詳細はあまり明らかになっておりません。 '03.4.5 Mach-4からGNUMachへと開発が進められています、海外ではx86系以外のPowerPCへの移植されている方もおられます、GNU Debian Linux 2.2でgcc-i386-gnuコンパイラーを用いてクロス開発が可能です、OSKit-Machでの他のLinuxなどのOS用デバイスドライバーソフトの移植も行えるようです。'03.08.08 ▼ セキュリティ強化のTrusted Mach '03.07.07 セキュリティ関係を強化したTrusted Machについては、フリーなのか、商用なのかは不明ですが、いずれMacOS XのMachに採用されるのではないかと思われます。'03.07.26 BeOSでは、マルチスレッドを意識せずとも付属のC / C++ コンパイラーでマルチスレッドなアプリケーション・ソフトの開発が可能です、カーネルとAPI関係など全てがマルチスレッド化されているため、その恩恵を受けるのです、GUI関係ではWindowの表示コードがマルチスレッド化されており、プリエンプティブ ( Preemptive ) なスケジューリング機能によりマルチプロセッサに自動的に割り付けられます。 BeOSでも、スレッドの排他制御はセマフォなどによるスレッド同期通信、そしてスレッドのロックとロック解除が可能ですが、Windows2000とは違ってBeOSの場合にはカーネルのスケジューリングと密接な関係があり、殆どカーネル関係の排他制御クラスにより制御されるのです。 スレッド関連クラスには、BLooper, BLocker, BAutolock, BMessege, BMessegerなどがあり、それらのクラスを使用しメソッドとしてのLock, Unlockでスレッド・プログラミングします。 Windows2000よりは革新的に進化したオブジェクト指向なBeOSでは、スレッドの排他制御以外のスレッド生成やメッセージ・パッシングとしてのスレッド間通信、メッセージとポート、共有メモリなどの機能を持っており、オブジェクト指向なマルチスレッド・プログラミングが可能です。 BeOSでは、バグのあるプログラムを製作しそれを稼動させた場合、バグのある表示Window領域内では、表示も異常状態となりマウスの操作もできませんが、他のWindow領域へマウスを移動すれば他のプログラムは正常に動きOS自体もハングアップやフリーズにも至りません、WindowsNT / 2000とは比較にならないほど格段に堅牢で安定しています、素晴らしいの一言です・・・。 まさにBeOSは、制御関係向きのOSと言えます、Be社が消滅してしまったことは大変残念でなりません、Be社はPalm社に買収されてしまいましたが、BeOSを消滅させることなく、Palm社はBeOSをOpen Sourceとすることに期待したいところです、フリーの開発者たちによるPC関係で普及させるように努力すれば必ずや復活することでしょう・・・。 GNUstepでのMacOS X のCocoaライクなNSThreadsなどのライブラリーを用いてマルチスレッド・プログラミングが可能です、GNUstepはFreeBSDやDebian Linuxなどに対応しており、NeXTstepのOpenStepのフリーなObjective-CのAPIライブラリーであり、Linux版のLinuxSTEPもあります。 ユーザーソースとスレッドAPIライブラリーはGNU Ojective-Cでコンパイルするか、或いはgcc ( ver. 2.8以降 ) でオプション指定でのObjective-Cソースのコンパイルが可能です、又オプションでスレッドの指定をすればユーザー・スレッド・ソースとスレッド・ライブラリーもコンパイルが可能です。 最近、間違った表現をされる方々が増えております、複数のスレッドがシングルプロセッサで同時に並列に動く、これはあり得ないことであり、マルチプロセッサならば同時に並列に動作するの表現が正しいでしょう。 スレッドはプロセッサ情報やタスク優先度情報, グローバル変数を参照する小さなサブルーチンのようなものであり、そのサブルーチンをカーネル・スケジューラがタイム・スライスしシーケンシャル ( 順次的 ) に稼動させているだけであり、並列に動作している訳ではないのです。 UNIXマシンでもマルチスレッド技術を応用しているが、古典的なforkとjoin ( 親プロセスは子プロセスの終了待ち ( Wait ) ) などの並列処理では、カーネル関連APIsなどのコール時のオーバヘッドが大きくなるため、その並列処理を改善する目的で、スレッド技術が考えられました。 タスクのコールのオーバーヘッドとスレッドのコールのオーバーヘッドは大幅な差異はなく10%程度であり、シングルCPUではマルチスレッドのメリットは殆どなく、Windowsプログラマー関係者は俗に言うマルチタスクとマルチスレッドを混同しており、マルチスレッドでなければ並列処理できない・・・とすればWindowsNT / 2000自体に欠陥ありと言うことになります・・・。 スレッドはMIMD方式の共有メモリ型対称マルチプロセッサ ( SMP ) マシンなどで並列処理をさせるため考えられたMachでの技術であったのです、そのスレッド技術をシングルCPUでもスレッド生成など時カーネルのオーバヘッドをできる限り少なくしパフォーマンス向上させるため利用されるようになったのです。 ◆ コンピュータと制御関係のページ |
||||||||
