OpenVMS Alpha
V7.3-2 リリース・ノート【翻訳版】

前へ 次へ 目次 索引

5.14 Mail ユーティリティ: 呼び出し可能メールのスレッドの制限事項

V7.1

OpenVMS 呼び出し可能メール・ルーチンはスレッド・セーフでは ありません。スレッド化されたアプリケーション内での非スレッド・セーフ・ルーチンの呼び出しの詳細については，『Guide to the POSIX Threads Library』を参照してください。

呼び出し可能メールのコンテキスト情報は，プロセス単位(スレッド単位ではない) で管理されるので，コンテキスト・ベースの処理を実行する複数のスレッドは相互に同期をとり，特定のタイプのメール・コンテキストが一度に 1 つ だけアクティブになるようにしなければなりません。この条件が満たされないと，1 つのスレッドが他のスレッドのメール操作を妨害する可能性があります。

OpenVMS Alpha システムでは，マルチスレッド環境でカーネル・スレッドが有効に設定されている場合，この他にも追加制限事項があります。この環境では，呼び出し可能メールは初期スレッドでのみ使用しなければなりません。

5.15 POSIX スレッド・ライブラリ

ここでは，POSIX スレッド・ライブラリ (旧名称は，DECthreads) に関する注意事項をまとめます。

付録 A.3 節 の関連する注意事項も参照してください。

5.15.1 C 言語コンパイル・ヘッダ・ファイルの変更

V7.3-2

OpenVMS Version 7.3-2 では，次の変更が行われました。

5.15.2 新しい優先順位調整アルゴリズム

V7.3-2

OpenVMS Version 7.3-2 では，『Guide to the POSIX Threads Library』で説明されている適応型スレッド・スケジューリング動作が，新しい優先順位調整アルゴリズムとともに実装されました。場合によっては，新しいアルゴリズムでは，優先順位が異なる，スループット方針のスレッドが同期オブジェクトを共用することによる問題を回避できます。優先順位の調整により，アプリケーションのスループットや，システム全体の使用状況も改善できます。スループット・スケジューリング方針のスレッドの優先順位調整は，自動で，透過的に行われます。

5.15.3 プロセス・ダンプ

V7.3

POSIX スレッド・ライブラリで実行時に修正不能な重大エラー (アプリケーション内のデータ破損によって損傷したデータ構造など) が検出されると，ライブラリにより実行中のイメージが終了されることがあります。終了中に，ライブラリによりプロセス・ダンプ・ファイルの作成がトリガーされます (このファイルは， ANALYZE/PROCESS_DUMP によりエラー診断に使用されます)。このようなプロセス・ダンプ・ファイルのサイズは，エラー時のプロセスのアドレス空間に依存するため，非常に大きくなることがあります。

5.15.4 動的 CPU 構成の変更

V7.3

OpenVMS Version 7.3 以降，POSIX スレッド・ライブラリは，マルチプロセッサ Alpha システムを実行する CPU の数の動的変化に対応するようになりました。 1 つのイメージに対して，複数のカーネル・スレッドが使用できるように指定 (LINK/THREADS_ENABLE 修飾子または THREADCP コマンド動詞により) すると， POSIX スレッド・ライブラリが，アプリケーションの明白な並列処理を監視して，利用可能な CPU の数を最大とする数のカーネル・スレッドを作成します。それぞれのカーネルスレッドは，OpenVMS エグゼクティブによってスケジューリングされて別々の CPU で実行されるので，同時に実行することができます。

アプリケーションの実行中，オペレータは CPU を個別に停止または開始することができます。このような動的変化を反映して，これ以降にイメージがアクティブ化されたときに作成できるカーネル・スレッドの数が変化します。また，現在実行中のイメージにも反映されるようになりました。

CPU を追加または除去すると，スレッド・ライブラリは，追加，除去後のアクティブな CPU の数を照会し，プロセスが現在使用しているカーネル・スレッドの数と比較します。現在 CPU がカーネル・スレッドよりも多い場合，ライブラリは既存の POSIX スレッドを CPU まで延長します (必要に応じて，すぐに，または後に新しいカーネル・スレッドを作成します)。逆に CPU がカーネル・スレッドよりも少ない場合，ライブラリは余分のカーネル・スレッドを強制的にハイバネートさせ，残りのカーネル・スレッド上で POSIX スレッドを再度スケジューリングします。これにより，プロセスに関する限り，利用可能な数以上のカーネル・スレッドが， CPU リソースを奪い合うということがなくなります。

5.15.5 スレッド・プログラムの高度デバッグ

V7.3

POSIX スレッド・ライブラリは，監視ツールとデバッグ・ツールをサポートするための，高度なデータ収集機能を備えています。これらの機能は， OpenVMS Alpha システム上のスレッド・プログラムのための新しいデバッグ，分析ツールであるビジュアル・スレッドをサポートします。ビジュアル・スレッドは，OpenVMS Version 7.3 でライセンスされており，監視機能，自動デバッグ機能，およびマルチスレッド・アプリケーションの性能評価機能を備えています。

5.15.6 デバッガ計測機能は動作しない

V7.0

POSIX スレッド・デバッガの計測機能は動作しません。

『Guide to the POSIX Threads Library』の C.1.1 に記載されている，動作中のプログラムをデバッグする手順を使用すると，プロセスが ACCVIO メッセージで失敗する可能性があります。

5.16 特権付きインタフェースとデータ構造体

ここでは，特権付きコードとデータ構造体の注意事項をまとめます。

5.16.1 スレッド単位のセキュリティは特権付きコードとデバイス・ドライバに影響する

V7.3-1

Version 7.2 では，セキュリティ・プロファイルを I/O Request Packet (IRP) に添付するために使用される方法が変更されました。

OpenVMS の Version 7.2 より前のバージョンでは，要求者のプロセス単位の Access Rights Block (ARB) セキュリティ構造のアドレスは IRP 構造に含まれていました。OpenVMS Alpha Version 7.2 以降，新しいセキュリティ・プロファイル構造 (Persona Security Block，PSB) のアドレスは， ARB アドレスの機能置換として IRP に追加されました。

I/O サブシステムは PSB 内の参照カウンタを介して，PSB へのアクセスを管理します。 I/O サブシステムは IRP の作成時にこの参照カウンタを増分し，その IRP の I/O の後処理時にカウンタを減分します。このカウンタが 0 になると， PSB 構造はデッドロック状態になります。

1 つの要求に対して複数の I/O 操作を行うために IRP のコピーを作成またはクローンし，コピーした IRP を後処理のために I/O サブシステムに渡すデバイス・ドライバは，これらの追加の IRP の PSB への特別な参照を明らかにするために，コードを変更しなければなりません。このような変更は，コピーされた IRP にある PSB アドレスを NSA_STD$REFERENCE_PSB ルーチンに渡すことで行います。 NSA_STD$REFERENCE_PSB のインクルード・ファイルとルーチン呼び出しは次のとおりです。 


#include <security-macros.h> 
 
/* Increment REFCNT of PSB that is now shared by both IRPs  */ 
 
nsa_std$reference_psb( irp->irp$ar_psb );

デバイス・ドライバは，次の状況でこの変更を行わなければなりません。

このような状況で NSA_STD$REFERENCE_PSB を呼び出さないと，PSB 内の追跡情報が破壊され，システム障害が発生する可能性があります。

NSA_STD$REFERENCE_PSB を呼び出すようにデバイス・ドライバのコードを変更する場合は，OpenVMS Version 7.2 以降で動作するように，ドライバを再コンパイルおよび再リンクしなければなりません。

5.16.2 OpenVMS フォーク・スレッド作成のための IPL 要件の強制

V7.3-1

OpenVMS フォーク実行スレッドを作成するためには，いくつかのルーチンを特権コードで使用します。これらのルーチンは，任意のプロセスのシステム・コンテキストに依存しないで実行されます。これらのルーチンには 4 つの形式があり，どの形式を使用するかは，直系のフォークとキューに入っているフォークのどちらが必要かと，使用されている言語インタフェースで決まります。

これらのルーチンは，実行中に，誤って別の CPU に再スケジュールされないようにするため， IPL$_RESCHED 以上で呼び出す必要があります。このような再スケジュールが行われると，システムがハングする可能性があります。

OpenVMS V7.3-1 では，SYSTEM_CHECK の値を 1 に設定すると，これらのルーチンによって，まずシステムの IPL がチェックされます。 IPL が IPL$_RESCHED の値よりも小さい場合，システムは SPLINVIPL バグ・チェックで失敗します。

性能上の理由から，SYSTEM_CHECK の値を 0 に設定すると (デフォルト)， IPL は検証されません。不正なコードを使用すると，プロセス・コンテキストでこれらのルーチンの実行中に別の CPU への再スケジュールが発生した場合は (IPL$_RESCHED よりも小さい値を指定した場合など)，システムがハングする可能性があります。

5.17 RTL ライブラリ (LIB$)

ここでは，LIB$FIND_IMAGE_SYMBOL の注意事項をまとめます。

5.17.1 LIB$FIND_IMAGE_SYMBOL: 『OpenVMS RTL Library (LIB$) Manual』の正誤情報

V7.3-1

『OpenVMS RTL Library (LIB$) Manual』の， LIB$FIND_IMAGE_SYMBOL に対する flags 引数の説明には誤りがあります。 flags は，参照渡しとして説明されていますが，この記述は誤りで，戻り値としてエラー・メッセージ LIB-F-INVARG が返されます。 flags を値で渡すと，LIB$FIND_IMAGE_SYMBOL は問題なく機能します。

この誤りは，『OpenVMS RTL Library (LIB$) Manual』の次の改訂版で修正される予定です。

5.17.2 LIB$FIND_IMAGE_SYMBOL シグナル通知による警告

V7.1

LIB$FIND_IMAGE_SYMBOL は，起動されているイメージにコンパイル警告が発生したモジュールが含まれていることを示すために，警告 (LIB$_ EOMWARN) を通知することがあります。LIB$FIND_IMAGE_SYMBOL で使用される条件ハンドラは，この状況を特殊な場合として取り扱わなければなりません。

LIB$_EOMWARN が通知された後，LIB$FIND_IMAGE_SYMBOL が実行を続行するには，条件ハンドラが SS$_CONTINUE で終了しなければなりません。この理由から， LIB$FIND_IMAGE_SYMBOL の条件ハンドラとして LIB$SIG_TO_RET を使用することは適切ではありません。

5.18 Screen Management (SMG$) のドキュメント

『OpenVMS RTL Screen Management (SMG$) Manual』の最後にある参照情報のトピックに，次の情報を追加します。

V7.2

V7.1

前へ 次へ 目次 索引