<!--
   $FML: lock.sgml,v 1.6 2008/08/18 20:52:59 fukachan Exp $
-->


<chapter id="lock">
	<title>
	ロック
	</title>

<para>
プロセス間の同期化はロックを用いて行ないます。
&fml8; でサポートされているロックメカニズムは 
flock(2) もしくは lockf(2) を元にしたロック機構のみです。
</para>


<sect1 id="lock.overview">
	<title>
	ロックの概要
	</title>

<para>
ながらく giant lock でしたが、2003/03 に giant lock をなくしました。
</para>

<para>
現在では、いろいろなりソースごとに、ロックチャンネルが用意されています。
</para>

<para>
たとえば、Mail::Delivery 関連はメンバーリストにアクセスするので、
いろいろとロックが必要です。
</para>

<para>
Mail::Delivery::SMTP の操作の際にはメンバーリストのロックが必要です。
現在は、Mail::Delivery::SMTP を呼び出す FML のクラス(実は FML::Send と 
FML::Process::Delivery の２箇所しかない)の中でロック処理をしています。
</para>

<para>
一方、Mail::Delivery::Queue は見るだけ (mailq コマンド)か、
並列操作可能なものだけなので、ロックは考えなくて良いはずです。
</para>

<para>
そして、reader writer lock まで大げさでなくとも
一般に map を使うモジュールにはロックが必要です。
write 用の lock が必要とは限りません。
たとえば
FML/Command/UserControl.pm 
や
FML/Command/Auth.pm
には write 用の lock が必要ですが、
FML/Credential.pm
は read 用の lock だけでよいです。
</para>

<para>
しかしながら、いまのところ reader writer lock は実装されていませんので、
リソースごとの細かいロック制御で critical region 
の時間を短くするようになっています。
</para>

</sect1>


<sect1 id="lock.todo">
	<title>
	TODO
	</title>

<para>
*_maps をよぶ前には MUTEX でロックをする。いや、やりすぎかもしれません。
</para>

<para>
メンバーリストへ IO::Adapter をかます時に、
READER WRITER LOCK がほしい。
<footnote>
<para>
READ ロックは不要か？いや、だめだろ
chaddr の途中で sleep したら敗けやから;)
</para>
</footnote>
perl thread をつかえばできるけど、
汎用的な実装はかなりむつかしいぽい;)
</para>

</sect1>


</chapter>
