略歴に述べたように、ピウスツキは流刑された10数年の間に樺太アイヌ、ギリヤーク、オロッコなどの写真・音声資料を多量に残した。特に蝋管は200から300本残したといわれているが、その多くは現在では行方不明である（ロシアなどで見つかる可能性はある）。現存する蝋管は、現在では最古の樺太アイヌ語の音声資料として重要である。日本では北海道大学を中心としてピウスツキの資料研究が進められており、1983年にはポーランドのザコパネに残されていた64本の蝋管が北海道大学に貸与され、再生及び分析が行われた（この時内容の調査に協力したのが樺太アイヌ語の最後の話者とされる浅井タケである。樺太アイヌ語の研究者村崎恭子も参照）。
スレッドの場合、関連付けられたデータにアクセスする前にロックを獲得するよう各スレッドが協力するものであって、ロックに強制力はない（これを助言ロック; Advisory lock と呼ぶ）。システムによっては強制ロック (Mandatory lock) を実装しており、ロックされたリソースに許可されていないアクセスを行おうとしたときに例外が発生するようになっている。（2値の）セマフォは最も単純なロックである。共有モード（リードオンリー）か排他モード（リードライト）かは区別されない。他の方法では、複数のスレッドがリードオンリーアクセスのためにロックを共有する共有モードを用意している。共有 (shared)、排他 (exclusive)、削除目的 (intend-to-exclude)、更新目的 (intend-to-upgrade) などのモードが広く実装されている。以上のようなロックの種類とは別に、ロックによってスレッドの進行が妨げられたときの動作によっても分類できる。多くのロックは、ロックされたリソースへのアクセスが可能となるまで、プロセスの実行をブロックする。スピンロックは単純にロックを獲得できるまでスレッドが待つ（スピンする）。これは待つ期間が短い場合は効果的で、オペレーティングシステムによるプロセスのスケジューリングのオーバヘッドもかからない。ただし、長時間ロックされたままの場合は非常に無駄である。
ロックは，複数の動作主体が同一のリソースに対して状態を変更する動作を行う時，不整合な状態が起こらないように制御する並行性制御において用いられる手法の一つである．ある動作主体がロックしたリソースへは，基本的には他の主体による利用は妨げられる．実際には，完全に利用をさせないロックは性能低下が著しいため，複数の主体が取得可能なロックや，他者の読み出しのみ許可するなど，複数のモード（レベル）のロックを用意し必要に応じて使い分ける．一言でロックといった場合でも，他主体の動作を妨げる基本的機能だけを指す場合，妨げられた主体の待ち動作を含む場合とさまざまである．動作主体としてプロセスの場合，プロセス間ロック機構がOSによって提供される．スレッドであれば，スレッドライブラリやスレッドを制御するスレッド機構により提供される．動作主体がトランザクションであれば，トランザクションモニターにより提供される．あるいは，リソースがファイルであればファイルロックとなる．
情報工学におけるロック (lock) とは、計算機システム内に複数の動作主体（プロセス，スレッド等）のある環境で、データやデバイスなどのリソースへのアクセス制限を課す同期機構。ロックは並行性制御ポリシーを実施する手法のひとつである。アクセス制限を課す動作を「ロックする」，「ロックを取得する」などと表現する．また対義語として，制限を解除することをunlock（アンロック，ロック解放，ロック解除）と言う．
KADOKAWAの文庫レーベル（カドカワのぶんこレーベル）では、株式会社KADOKAWAが発行・発売もしくは同社に吸収合併された角川グループパブリッシング（角川GP）が発売元となっていた文庫本のレーベル一覧について、各ブランド（旧ブランドカンパニー）別に記述する。
中央防犯サッカー部を経て、2009年に藤枝ネルソンCF（のちの藤枝MYFC）へ加入。2011年からはGKコーチ兼任でプレーを続けた（2013年は10月に選手登録）。2013年の天皇杯では斉藤俊秀選手兼任監督に代わり監督として2試合を指揮した。同年シーズン終了後、藤枝を退団した。
上のようなJITコンパイラの短所を補うためのJITコンパイルの一方式として適応的コンパイルという方式がある。これは、起動当初はインタプリタとして実行し、よく呼び出されるメソッドや繰り返し実行されるコードの検出（プロファイリング）を行い、そのようなコードのみをコンパイルする、というものである。このとき、コードが使われた時にすぐにコンパイルするのではなく、何回か呼ばれた後に遅らせてコンパイルを行うが、このことを遅延コンパイル (Lazy Compilation)と呼ぶ。一般にプログラムの実行においてその実行時間の大半はプログラム中のごく一部において費やされる、という経験則がある（実際の比率については状況に依存するが、典型的にはコードの実行時間の80%は20%のコードにおいて費やされるといわれ、80-20の法則と呼ばれる）。それと似て、適応的コンパイルにおいては実行時間の大半が費やされるような、ボトルネックとなるコードのみをコンパイルすることで、起動時のオーバーヘッドや利用メモリ増大を抑えたうえで、効率よく実行速度を向上することができる。この適応的コンパイルによる適応的最適化 (Adaptive Optimization) は、静的コンパイルでは得られない情報をも元にして最適化が行えるため、静的コンパイルより、むしろパフォーマンスが上がる場合もある。注意すべきは、企業のバッチ処理である。数百件以内といった少量レコードを処理するバッチジョブが、一日に何百本、何千本も走る企業が多い。そういう場では、JITコンパイルを用いた場合、適応的コンパイルをしてさえも、ジョブの走り初めに、使われるユーザクラスさらにはコアクラスと呼ばれるような共通的なクラスのコンパイル処理がロード処理を伴いのべ何百回と行われる。処理件数が少ないので、使うクラス群の多くはコンパイル効果が出る前に、あるいはコンパイルさえされないうちにジョブ実行が終わってしまう。その結果、正味のユーザロジックよりこうした「オーバヘッド」の方が大きな比率を占める。CPUなどの資源が、いつも同様のプログラム群のコンパイルに消費されてしまい、待ちが生じて多重効果の妨げにもなる。処理件数によってJIT/AOTの有利不利が変わるが使い分ける仕組みは非常に作りにくい。また、（Javaについていえば）AOTコンパイラを通常適用しにくい。これらの理由で、性能面ではマイナスな場面でも一般的なJITコンパイラを使用していることがある。長時間バッチジョブおよびオンラインでは、JITコンパイラ、特に適応的コンパイルが概してフィットしている。適応的コンパイルの最適化のために、何回実行されたらコンパイルするか、といったパラメタが用意されているコンパイラがある。パラメタチューニングは万能ではないとしても重要である。