14.13.2 InnoDB 相互排他ロックおよび読み取り/書き込みロックの実装

MySQL および InnoDB では、実行の複数のスレッドが共有データ構造にアクセスします。InnoDB は、これらのアクセスを相互排他ロックと読み取り/書き込みロックの独自の実装と同期させます。InnoDB は従来、InnoDB 相互排他ロックを使用して読み取り/書き込みロックの内部状態を保護してきました。Unix および Linux プラットフォームでは、IEEE Std 1003.1c (POSIX.1c) にあるように、InnoDB 相互排他ロックの内部状態は Pthreads 相互排他ロックによって保護されます。

多くのプラットフォームには、相互排他ロックと読み取り/書き込みロックを実装するためのより効率的な方法が存在します。アトミック操作を使用すると、多くの場合、Pthreads より効率的に複数のスレッドのアクションを同期させることができます。ロックを取得または解放する各操作をより少ない CPU 命令で実行できるため、共有データ構造へのアクセスのためにスレッドが競合している場合の浪費時間が少なくなります。マルチコアプラットフォーム上では、これがさらにスケーラビリティーを向上させます。

InnoDB は、以前に使用されていた Pthreads のアプローチを使用する代わりに、アトミックメモリーアクセスのための GNU コンパイラコレクション (GCC) によって提供される組み込み関数を使用して相互排他ロックと読み取り/書き込みロックを実装します。より具体的には、GCC バージョン 4.1.2 以降でコンパイルされた InnoDB は、pthread_mutex_t の代わりにアトミックビルトインを使用して InnoDB 相互排他ロックおよび読み取り/書き込みロックを実装します。

32 ビットの Microsoft Windows では、InnoDB は、手で書かれたアセンブラ命令を使用して (読み取り/書き込みロックではなく) 相互排他ロックを実装していました。Microsoft Windows 2000 からは、GCC によって提供される組み込み関数と同様の、インターロックされた変数アクセスのための関数が使用できます。Windows 2000 以降では、InnoDB はインターロックされた関数を使用します。手で書かれた古いアセンブラコードとは異なり、新しい実装では、読み取り/書き込みロックと 64 ビットプラットフォームがサポートされます。

Solaris 10 ではアトミック操作のためのライブラリ関数が導入され、InnoDB は、デフォルトでこれらの関数を使用します。アトミックメモリーアクセスのための GNU コンパイラコレクション (GCC) によって提供される組み込み関数をサポートしていないコンパイラを備えた Solaris 10 上で MySQL がコンパイルされた場合、InnoDB はライブラリ関数を使用します。

この変更によって、マルチコアシステム上の InnoDB のスケーラビリティーが向上します。この機能は、それがサポートされているプラットフォーム上で標準で有効になります。パフォーマンスの向上を利用するためにパラメータやオプションを設定する必要はありません。アトミックメモリーアクセスのための GCC、Windows、または Solaris 関数が使用できないプラットフォームでは、InnoDB は、相互排他ロックと読み取り/書き込みロックを実装するための従来の Pthreads の方法を使用します。

MySQL が起動すると、InnoDB は、アトミックメモリーアクセスが相互排他ロックに使用されるか、相互排他ロックと読み取り/書き込みロックに使用されるか、またはどちらにも使用されないかを示すメッセージをログファイルに書き込みます。適切なツールを使用して InnoDB が構築されており、かつターゲット CPU が必要なアトミック操作をサポートしている場合、InnoDB は、相互排他ロックに組み込み関数を使用します。さらに、スレッド識別子 (pthread_t) で比較およびスワップ操作を使用できる場合、InnoDB は、読み取り/書き込みロックのための命令も使用します。

注記

ソースからビルドしている場合は、そのビルドプロセスがプラットフォームの機能を正しく利用していることを確認してください。

ロックのパフォーマンスへの影響の詳細は、セクション8.10「ロック操作の最適化」を参照してください。