Blogプログラミング・IT関連。知っていると便利なこと、気になって調査したこと、はまったけど解決できたことなど。Platformにはmingwが同梱されておりgccが含まれています。2014.2.0.0をインストールしているのですが、これに付属されているgccでC++11のコードをコンパイルしようとすると、以下のようなエラーになってしまいました。'-std=c++11'-stdオプションで"c++11"を指定しても、認識してくれません。4.7でサポートされたようです。2014.2.0.0に付属されているgccのバージョンを確認したところ、4.6であることがわかりました。PURPOSE.gccは4.6で、'-std=c++11'オプションは認識できないバージョンであるため、冒頭のエラーとなってしまいます。gcc4.6でもC++11(相当)コードをコンパイルする方法はあります。4.3~4.6では'-std=c++0x'と指定すれば。以下のように実行すればコンパイルすることができます。SQLiteのロック・トランザクション関連仕様の整理SQLiteは共有ロック・排他ロックの仕組みを備えており、プロセス内の複数スレッド、だけでなく、プロセスをまたぐ状態でSQLが同時に発行されても適切に処理されます。トランザクションに複数のモードが存在し、指定するモードに依って取得されるロックが変わります。SQLの内容に依存してロック状態が遷移するため、複数プロセスがアクセスしたときの挙動を正確に把握できるよう、仕様を整理してみました。(文中の「プロセス」は、正確には「プロセス、もしくはスレッド」を意味します。)DBのロック状態の種類:UNLOCKEDロックされていない状態。誰も読み書きしていない。SHAREDread可、write不可な状態。複数プロセスが同時にSHAREDロックを取得可能。複数プロセスが同時にreadできることを意味する。DBがこの状態にあるとき、他のプロセスからのwriteはもちろん不可。RESERVEDRESERVEDロックは、プロセスが将来writeを行う予定であるが、現時点ではreadだけを行っている状態である。SHAREDロックは複数プロセスが同時に取得することができるが、RESERVEDロックを取得できるのは1プロセスに限定される。PENDINGロックとの違いは、新たにSHAREDロックを取得できる点(RESERVEDロック中であれば、別プロセスが新たにSHAREDロックを取得できるが、PENDINGロック中は新たにSHAREDロックを取得することはできない)。SQL実行におけるwrite処理がキャッシュ上で完結する場合は、このRESERVEDロック状態で実行される。PENDINGPENDINGロックは、既存のSHAREDロックの解放を待ち、EXCLUSIVEロックを取得してwriteを実行しようとしている状態である。PENDINGロック状態では新たなSHAREDロックの取得は許可されない。既存のSHAREDロックはそれが解放されるまでは有効。EXCLUSIVEEXCLUSIVEロックはDBファイルへのwrite実行時に必要なロックである。あるDBファイルの中では、ただ一つのEXCLUSIVEロックだけが有効になることができる(このとき、その他の全てのロックは解放された状態になる)。SQLiteは並列処理性能を最大化する目的で、EXCLUSIVEロックの取得時間を最小にするよう動作する。3トランザクションの開始:明示的にトランザクションを開始する、しないに関わらず、DBの更新ではかならずトランザクションが実行されます。TRANSACTIONを明示的に実行した場合には、COMMITもしくはROLLBACKを実行するまでトランザクション状態が継続されるトランザクションのモード:DEFERREDデフォルトはこのモード。トランザクションを開始した後でも、実際にDBに対するアクセスが発生するまではどのロックも取得しない。最初のread処理でSHAREDロックを取得し、最初のwrite処理でRESERVEDロックを取得する。TRANSACTIONが成功してしまう点には注意が必要)。TRANSACTION実行時にRESERVEDロックを取得する。connectionも、DBへのwrite、IMMEDIATE/EXCLUSIVEトランザクションの開始はできなくなる。TRANSACTION実行時にEXCLUSIVEロックを取得する。connectionでreadが禁止される。connectionにおいてwriteが禁止される。各トランザクション開始時にどのロックが取得されて、そのロック状態がどう遷移するのかがわかりにくかったため、絵にまとめました。以上、SQLiteの動作理解の助けになれば幸いです。