ファイルロックしなくても絶対に壊れないカウンター

があるとしたら信じます？一応作ってみたんですが・・・。
カウントアップのシミュレーションプログラムを作成しましたので、
どこまで壊れないのか、検証していただけるとありがたいです。
ちなみに、
・テンポラリーファイルに一旦書き出して、Ｒｅｎａｍｅ。
・セーブファイルにも同時に書き出しておいて、壊れたら、そこから復旧。
・上書き方式ではなくて追記方式。
のいずれでもありません。
でも、ロックしなくても壊れない・・と思います。多分。

http://www.interq.or.jp/white/nora/idx1000.html

興味がおありの方は、どうぞ。お待ちしております。
えー、トップページのカウンターは現在のところ、「とほほカウンター」を
使用させていただいています。

ソースがあるなら、見てあげるよ。
ソースがなければ検証もなにもない。

・count_logディレクトリ内のファイルの数を数える方式

・カウントデータのファイル名を見る方法（カウントアップ=リネームそのもの。書き出し不要）

＞2
すいません。「検証」という言い方がまずかったと思います。
シミュレーションプログラムを作成したので、実際に動かしてみて
壊れるのかどうか、テストしていただきたいと思ったのです。
「自分でやれば？」と言うかも知れません。もちろん自分でもやっています。
いまのところ壊れる様子はありません。
ソースはいずれ公開したいと思いますが、当面は控えさせていただきたいと
思います。そんなたいしたものでもないとは思うのですが、どなたかに
「こんなロジックだろ？」と当てられてしまうまでは、取り合えず公開しません。
あつかましいかも知れませんがよろしくお願いいたします。
＞3違います。

＞4違います。

すごい！天才ですね！

ちなみに私も昨日、絶対に落ちないOSを開発しました。
ソースは公開できませんが。

>のら
おまえのクイズに付き合ってる暇は無いんですがね。

どうでもいいよ、こんなの。
無視。

いいんじゃないの。付き合ってあげようよ。
かまって欲しいのはどのスレッドの人も一緒だよ。

>7
天才ではありません。だれでも思いつくことだろうと思います。
「絶対に壊れない」という言い方が反感をかったのでしょうか？
ちょっと大げさだったかもと、反省しています。
「ファイルロックしなくても壊れにくいカウンター」ではいかがでしょうか。
>8
お付き合いいただいて、ありがとうございます。
お時間のあるときだけで結構ですので、どうかご協力ください。
>9
どうでもいいということは、ないと思います。
無視しないで下さい。

>10
ありがとうございます。感謝します。

ばかでも低脳でもこういう面倒見の良い奴が社会では重宝されるんだよね。
まあｶﾞﾝﾊﾞﾚ＞のら

＞ファイルロックしなくても壊れにくいカウンター
だったらファイルロックをすればもっと壊れにくいカウンターになるのか？

renameですりかえるだけで、ロックしなくても壊れないよ。
読んでから書き戻すまでに重複すれば取りこぼすことはあるけど、
unixだとすでにopenされてるものはrenameで消されても
closeするまではそのまま以前の状態が生きてるから。
renameが、あとみっくだっけ？あれならたとえプロセス殺されても
カウント数が失われることも無い。
とりこぼすとダメって場合はロックする必要があるけど。

こんなもんでどーよ？

あ、renameじゃねーのか。じゃ、わからん。

>13
まあ、挑発するような言い方はやめましょうよ。

横道にそれそうなので、ちょっと質問させていただきたいと思います。

ファイルが壊れるときというのは、突き詰めていけば、この処理が
根本的な原因だと思うのですが、どう思われますか？
つまり上書きで書き出すために、ファイルをオープンしたときに
クリアされてしまう。この後にデータを書き込むまでのわずかな間に
ジョブがこけてしまったり、他の人が読み込み処理をおこなってしまったら、
もうアウトですよね？違いますか？

open(OUT＠｀ "> $file_cnt");

それと、もうひとつ質問です。

open(IN＠｀"$file_cnt");
$cnt = <IN>;
close(IN);

普通の読み込みの処理ですが、この処理に異常が起きる確立って
どのぐらいなのでしょうか？
この例でいえば、$file_cnt にはデータがあるのに、
処理を抜けてきたら、$cnt　には、何もセットされていなかった。
というような事って、ないとはいえませんがものすごい低い確立のような
気がしますがいかがなもんでしょう。この場合も完璧にデータは壊れてしまいますよね。

>14
なると思います。ただ、
「もしも壊れちゃったらその時はしょうがないや」とか、
「よほどアクセスが一瞬の間に集中する場合」とか、
「ファイルロックして、リトライするためのレスポンスの悪化が
いやだ。」
とかいう場合には、ロックする必要がないくらい、壊れにくいとは
思います。
>15
renameの処理というのは、実際には「読んで」「書く」という処理
を行うのでしょうか？だとしたら、あくまでも論理上のものすごく
低い確立の話ではありますが、「読んで」「書く」間に他の人に
空のデータを読まれてしまう可能性はあるわけですよね。
>closeするまではそのまま以前の状態が生きてる
ということであれば、ジョブがこけた場合は大丈夫ということですね。
>renameが、あとみっくだっけ？
すいません。あとみっくって何ですか？

結論から言えばrenameではありません。
>16
まあ、そう言わないで・・・。

>低い確立の話ではありますが、「読んで」「書く」間に他の人に
>空のデータを読まれてしまう可能性はあるわけですよね。

可能性がないから壊れないと言ってる。
図でも書いてみて、実際にテストしてみるといいよ。

一般的にCGIはどうやると壊れるの?

>19
もちろん机上の論理上の話ですから、実際の運用に支障は
でないと思いますし、何千回テストしてみても、壊れない
だろうと思います。コンピュータの中で行われる、何百、
何千秒分の一というわずかな瞬間の処理をものすごく拡大して
スローにして論理上でシミュレーションしてみた場合の話です。

>20
「カウンターが壊れるとき」を目で確認できるシミュレーション
プログラムもご用意してあります。よろしければご覧下さい。

http://www.interq.or.jp/white/nora/idx1000.html

15の話が本当だとしたら、わずかな瞬間も何も
壊れるはずがないと思うんだけど…。

っていうか、なんでソース見せてくれないんですか？＞のら氏
なんの証拠も出さず、開発したのは本当だからテストに協力してくれ、
って虫が良すぎませんか？
不完全だった場合の揶揄が嫌だったり、パクられるのが嫌なのなら
そもそもこんなスレたてないでくださいな。

ヒールから善玉レスラーに転向してください＞のらさん

というかソース読みたい。

教えてくれないなら考えて答えを書いちゃいます。

くだらないスレたててる暇があったら、プログラミングの勉強でもしようよ。

1. ファイルロックはOSが提供する排他制御のための機能に過ぎません。
ファイルロック以外にも、カーネル内部では無数のmutexを使っています。
その中には、アプリケーションから排他制御のために流用可能なものもあります。
でもそれらを流用したところで、ファイルロックを使ったときと同等の処理を
ファイルロックを使うよりも悪い実行効率で行うだけなので
ちっとも嬉しくありません。
ファイルロックを使わない場合があるのは、移植性や環境に起因する問題
(主としてNFS絡みの)を回避するためで、それだけです。

2.吉崎栄泰氏の爪の垢でも煎じて飲んでみてください。

アトミックって何ですかって時点でネタスレのような気がするが。

中学生なら、アトミックとかの言葉を知らないのはしょうがないんじゃないかな。

考えたら解ったので寝る。お休みなさい。

>19
renameの書き込みの処理って、こういう手順ですか？

temp.file <- 書き込み

counter.file <- temp.file rename


この処理が実際には、

temp.file <- 書き込み　1.

temp.file -> 読み込み　2.

counter.file <- 書き込み　3.

temp.file <- うまくいったら削除？

と言うことでしょうか。自信ありませんが・・
だとしたら、21のレスは私の勘違いです。すみませんでした。
3の処理が異常終了しても、復旧されるということでしょうか。

renameの処理について不完全な理解をしていたために誤解を
与えてしまったようです。
正直なところ、処理はちょっと似ています。

>22
>不完全だった場合の揶揄が嫌だったり、

嫌じゃありません。ソースはいずれ必ず公開します。

>パクられるのが嫌なのなら
パクられるほど、良いものであったらいいなと思っています。

>23
あらら、私、ヒールになっちゃってます？
すぐにソース公開しなきゃだめなんでしょうか。

>24
プログラミング勉強中です。

>25
ネタではありません。
>26
中学生じゃありません。
>27
おやすみなさい。わたしも寝ます。

read counter.file
count up
write temporary$$.file
rename temporary$$.file -> counter.file

だよ。renameが何をしてるか根本的に勘違いしてるみたいだから
理解できないだろうけど。

小学生でスクリプトが書けるとはスゴイ！

結局、一睡もできません。いろいろと考えてしまって・・・。
このスレッドに来ていただいている皆様は、少なからず
プログラミングに関わりのある方々だと思います。
恐らく、既存の処理にとらわれすぎているのでは
ないでしょうか。といっても既存の処理がまずいと言っているのでは
決してありません。ただ、選択肢は多い方が良いのでは
ないかと思うのです。ホームページに取り付けるカウンター
ひとつとってみても、さまざまな業種の方や個人がさまざまな目的で使う
のですから、それぞれのニーズにあった処理を選ぶべきです。
カウントの正確さ重視、レスポンスを重視、見栄えを重視、
付加機能を重視。それぞれだと思います。そのためには、
いろいろな選択肢が用意されていた方がいい。.....続く

renameの処理にしても、素晴らしいと思います。ただそれだけに
とらわれていては、新しい発想は何も生まれてこないと思います。
正直に言いましょう。私はperl言語に関して、初心者です。perl
という言語を初めて耳にしてから、１年も経ちません。ましてや
perlでプログラムを組んでみたのも、ここ１ヶ月ほどのことです。
カウントアップの処理手順を考えてみたとき、renameという処理
があることを知りませんでした。逆にいえば、知らなかったから
そういう処理手順を思いついたのかも知れません。動かしてみたら、
確かに壊れにくい。でもこれは、多分、何処かで誰かが、やっているだろう。
と思いました。でもひょっとしたら、という思いもありました。
だから、このスレッドをこういう形で立ち上げたのです。.....続く

ぱくられるのがいやだというわけではなく、
結局、たいした事はないものだと発覚しても、もしこのスレッドの中で、
これだけのプロの方々が集まって、あれやこれや議論する中で、
新しい発想が生まれたならそれはそれですごいことではないてすか。
たとえ、ネタであったとしても、十分収穫のあったスレッドという
ことになるはずです。違いますか？

「検証してやるからソースを見せろ」という気持ちもわからないでは
ありませんが、素人のつくったものを、プロが自信たっぷりに眺めて
欠点をあら捜しするのはあまりいい行為だとは思えません。
（念のために申し上げておきますが、「あら捜し」と「ご指摘」はまた
意味が違うと思います。）

こうなったら、正解がでるまで、意地でもソースは公開しません。
当ててください。

またまた念のために申し上げておきますが、誰かが正解を言ったあとで
ほかの人が「何じゃ、あほくさ」というのは、なしですよ。　　　終わり

CGI板にもなかなかいい逸材が転がってるじゃないか。見直したよ。

どこまで壊れないかって... 通常、カウンタ等のストレス
テストをするには、同時にすさまじい量のコネクションを
サーバに対して張るなどの手法をとらなければなりません。
すくなくとも共用レンタルサーバ使ってやってみる話じゃないよ。
まじな話、サーバの管理者や他の利用者に対する迷惑を考えなさい。

あっさり壊れたぞ(;ﾟ;Д;ﾟ;)y-~~>1
8340 8341 8342 8343 8344 8348 8350 8352 8353 1
あ！ 1 がでましたね。何かいいことがあるかも知れません（＾-＾）
8357 8359 8360 8361 8362 8363 8365 8367 8370 8373 8373 8377 8377 8380 8381 8381 8383 1
あ！ 1 がでましたね。何かいいことがあるかも知れません（＾-＾）
8387 8388 8390 8392 8393 8394 8395 8396 8397 8398 1
あ！ 1 がでましたね。何かいいことがあるかも知れません（＾-＾）
8401 8402 8403 8404 8405 8407 8408 8409 8410 8412 8416 8417 8418 8419 8427 8430 8431 8434 8435 8436 8440 8442 8444 8445 8445 8447 8448 8450 8451 8453 8455 8458 8460 8460 1
あ！ 1 がでましたね。何かいいことがあるかも知れません（＾-＾）
8465 8467 8471 8474 8475 8476 8477 8478 8480 8482 8484 8486 8487 1
あ！ 1 がでましたね。何かいいことがあるかも知れません（＾-＾）
8487 8490 8492 8494 8496 8498 8500 8502 8504 8506 8508 8512 8513 1
あ！ 1 がでましたね。何かいいことがあるかも知れません（＾-＾）
8516 8517 8520 8522 8526 1
あ！ 1 がでましたね。何かいいことがあるかも知れません（＾-＾）
8531 8536 8538 8542 8546 8550 8552 8553 8553 8555 8555 8560 8564 8568 8569 8570 8571 8572 8574 8576 8580 8582 8584 8586 8590 8591 8592 8592 8593 8594 8595 8596 8597 8598 8599 8600 8601 8602 8603 8604 8605 8606 8607 8608 8609 8610 8611 8612 8613 8614 8615 8616 8617 8618 8619 8620 8621 8622 8623 8624 8625 8626 8627 8628 8629 8630 8631 8632 8633 8634 8635 8636 8637 8638 8639 8640 8641 8642 8643 8644 8645 8646 8647 8648 8649 8650 8651 8652 8653 8654 8655 8656 8657 8658 8659 8660 8661 8662 8663 8664 8665 8666 8667 8668 8669 8670 8671 8672 8673 8674 8675 8676 8677 8678 8679 8680 8681 8682 8683 8684 8685 8686 8687 8688 8689 8690 8691 8692 8693 8694 8695 8696 8697 8698 8699 8700 8701 8702 8703 8704 8705 8706 8707 8708 8709 8710 8711 8712 8713 8714 8715 8716 8717 8718 8719 8720 8721 8722 8723 8724 8725 8726 8727 8728 8729 8730 8731 8732 8733 8734 8735 8736 8737

あ。これは違うのか..

1が電波プログラミング道を実践するのは勝手なんだが（ていうか、もはや矯正不可能）
右も左もわからない初心者がそれに巻き込まれるのは辛いな。

> こうなったら、正解がでるまで、意地でもソースは公開しません。

そんなこと言わずに、絶対壊れないという素晴らしい天才的な
ソースを右も左もわからない初心者の私にも見せてください。
お願いです。
プロの方に対してならいざ知らず、私のような初心者に対してまで、
いぢわるでソースを見せないというのは、あまりいい行為だとは思
えません。
仕様通りに動くか動かないかの乾いたプログラムの世界で、人の
道を語ってしまうあなたを本当に尊敬してるんですから。

サーバーの製作手法みたいに無限ループにして
カウンタのファイルの中身があるときだけ
読むようにしているのとは違うのか?

しかしこんな低レベルの原理じゃないんですよね。
のらさんおしえてください。

35がいいことを言っている

> こうなったら、正解がでるまで、意地でもソースは公開しません。

　こうなっては、恥ずかしくて、意地でもソースは公開できません。

の間違いです

■■■■■■■■■■■ 逝去 ■■■■■■■■■■■■■

あ！ 1 がでましたね。何かいいことがあるかも知れません（＾-＾）
33559 33560 33561 33562 33563 33564 33565 33566 33567 33568 33569 33570 33571 33572 33573 33574 33575 33576 33577 33578 33579 33580 33581 33582 33583 33585 33586 33587 33588 33589 33588 33590 33591 33592 33593 33594 33595 33597 33598 33599 33600 33601 33602 33603 33606 33608 33610 33614 33615 33616 33618 33622 33623 33624 1
あ！ 1 がでましたね。何かいいことがあるかも知れません（＾-＾）
2 3 4 5 6 7 8 10 12 14 16 17 18 19 20 21 1
あ！ 1 がでましたね。何かいいことがあるかも知れません（＾-＾）
25 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110

あっさり壊れるね。

あ〜あ。

３じゃないな

ほんとに壊れないの？
すげーじゃん。
ソース見たいな♪

質問です。
このスレッドでいうファイルロックって
perl関数のflockのことなんですか？
ロックの方法って
シンボリックリンク張るとか
(ダミーの)ファイルを作成するとか
いろいろあるみたいですけど。

>34
私にいっていただいているのでしょうか？だとしたら本当に嬉しいです。
ありがとうございます。

一個づつ皆様にレスしますので、しばらくお待ち下さい．．．

>35
御忠告ありがとうございます。おっしゃる通りなのだと思います。
皆様、こちらからテストをお願いしておいて、勝手だとは思いますが、
ＣＧＩプログラムの使用を一時中断させてください。プログラムそ動かなく
する作業はもう少し、あとになりますが、この後はプログラムの起動を控えてくださるよう
お願い致します。プロバイダさん問い合わせをします。

>36 37
そうですね、これはファイルのデータ自体は壊れてはいません。単にデータが読めなかった
だけなのだと思います。突発的に一個だけ　1　がでていますが。次のカウントからは復旧しています。

>38
>右も左もわからない初心者がそれに巻き込まれるのは辛いな。
私のことですよね？本当に辛いです。想像していた以上です。

>51の追加
これだけ、1　がたくさん出ているのは、私も初めてみました。
1　がたくさん表示されるということは、それだけファイルの読み込み
がバッティングしているということであって、通常だと１をそのまま書き込んでしまって
こわれちゃいますよね。でも復旧しています。

>39
「絶対に壊れない」といういい方は　11　で「壊れにくい」に訂正しています。
別に人の道を語っているわけでは、ありません。でも、私も偉そうな事をいっている割には、
3 4 さんへのレスの仕方は最悪ですね。申し訳ありません。もしよろしければ、その
処理実際の処理のスクリプトを教えて頂けないでしょうか。お願い致します。
というと「じゃあお前の方が先にソースを公開しろよ」という事になるんでしょうか・・う〜ん。

＞というと「じゃあお前の方が先にソースを公開しろよ」という事になるんでしょうか・・う〜ん。

それは当たり前ですな。
なんでそんなに公開したくないのかわからん。

>40
この処理が低レベルなのかどうか、私にはわかりませんが、その方法ではないと思います。
答は、低レベルだと思いますが・・・。
このレスが終わったら、これまでの内容をちょっと整理しながら、ヒントのようなもの
を出したいと思います。申し訳ありませんがもうしばらくお待ち下さい。

>41
おっしゃる通りです。

>42
恥ずかしいです。でも公開はします。

>43
はい、この場合、２回目の　1　で壊れています。白状してしまうと実は私も1回だけ壊してしまった事が
あります。はっきり言ってショックでしたが、いろいろ考えて、「こういう処理の手順になると壊れちゃうなあ」
という答にたどり着きました。やはり「壊れない」と言うのは無理なんでしょうか。

なんかこいつむかつくな。
本当は今必至こいて作ってるんじゃねーのか?

後、もう誰か言ってるかもしれないけど、一応俺も書いとくか。
・追加モードで1byte書き出す→ファイルサイズがカウント数
・ファイル名としてカウント数を書き込む

>44 45
「あっさり」なんでしょうか？昨日の夜から、どれだけの人がテスト実行
してくれたのか、全くわかりませんが、一応、壊れたのは、（掲示板に書き込みがあったのは）
>43の２回目の 1 のみ。1回だけです。

>>右も左もわからない初心者がそれに巻き込まれるのは辛いな。
>私のことですよね？本当に辛いです。想像していた以上です。

巻き込んでるのはオマエ、巻き込まれてるのはperl板住民だ。
良く読め。

ウソを言うな。
スタートボタン連打すればかなりの確率で壊れるぞ。
今もカウンタ戻ってるだろ。
http://cgi.members.interq.or.jp/white/nora/cgi-bin/nobreakcounter.cgi?loop=1

>46
３ではありません。なぜわかるのですか？
>47
壊れます。でも壊れにくいと思います。
>48
私への質問ではないと思いますが、一応。
「ロックしなくても壊れにくい」ので、どのロックもしません。

open(LOG＠｀">> count.dat");
print LOG "1";
close(LOG);

で
$cnt = -s count.dat;
で良いジャン。
ちがう？？

fj.lang.cの、なまおくん以来の逸材かもしれん。

結局、バッファをフラッシュして閉じるのがアトミックでないなら
潰れるってことだよ。途中に何挿もうが程度の問題でしかない。
その点はロックするかrenameするしか逃げ道は無い。

それでもあえてロックしないrenameしない、か？
誰もそんなカウンタ使わんが、ま、いいけどね（わら

>59
むかついたなら、あやまります。ごめんなさい。なにもあおっているわけでは
ないです。誤解です。
追加モード−＞1
ファイル名−＞4
にあります。いづれでもありません。
>61
すいません。勘違いでした。
>62
Count Up -> 1 のことでしょうか？これはループ回数でカウンター値では
ありません。カウンター値は今みたら1249 でした。

>64
open(LOG＠｀">> count.dat");
これって追記モードですか？本当に初心者ですいません。
この処理でもないみたいです。

すいません一旦レスを中断させてください。追っつかなくなってきました。

これまでの、整理をさせて下さい。

カウンター見るためにカウントアップ値を1にしただけだよ。
もう一回やってみた。
--------------------------------------------------
8626 8632 8636 8646 8713 8716 8717 8727 1
あ！ 1 がでましたね。何かいいことがあるかも知れません（＾-＾）
8729 8748 8796 8808 8815 8840 8859 14 16 34 46 88 102 14 144 150 236 240 254 264 280 274 285 308 309 311 312 338 1
あ！ 1 がでましたね。何かいいことがあるかも知れません（＾-＾）
400 462 462 462 463 464 465 466 467 468 468 469 470 470 474 474 475 478 494 496 506 511 514 524

すいません、「壊れるカウンタ」が壊れないんですけどぉ・・・(汗)

今見たら1087だよ。やっぱ壊れるね。

まず、私はrenameではないと言いました。お恥ずかしいのですが
プログラムを作った時点で私は、renameという命令を知りませんでした。
ファイルの入出力命令で、私が使えたのは、

open(IN＠｀"$file_cnt");
open(OUT＠｀ "> $file_cnt");

だけです。この命令を使用しています。
1で延べたように、
・テンポラリーにかきだして、壊れたら復旧。
・追記モード
でもありません。

ヒントは、
よむ　かく　かく　ではなく　よむ　よむ　かく　です。分かっちゃいましたか？

読み込んだサイズが0なら(正しい値が読み込めるまで)読み直すとか？

ヒントは良いからはやく恥ずかしいソースアップしてくれ。
別に煽ったりしないから。
誰でも、「あ、俺もしかして、すげー発見したのかも！？」って勘違いは
一度はあるものだ。

open(CNT＠｀"+<$Counter");
eval {flock(CNT＠｀2);};
$sum = <CNT>;
truncate(CNT＠｀0);
seek(CNT＠｀0＠｀0);
print CNT ++$sum;
close(CNT);

で十分。
素人が自前のロックシステムとかつくるのは
やめとけ。

truncateとseekはどうして必要なんですか？

http://wakusei.cplaza.ne.jp/twn/wwwperl2.htm#flock
読んでね。

ソースです。
http://www.interq.or.jp/white/nora/cgi-bin/nobreakcounter.cgi-sss640145.txt
一度　1 が表示されて、カウンターが復旧する場合の処理は、多分以下のような流れ
ではなかろうかと思います。
：
1.Ａさんがファイル１を読もうとしたが、よめなかった。　ファイル１のデータは152
2.Ａさんがファイル２を読もうとしたが、よめなかった。　ファイル２のデータは151
3.Ａさんのカウントは　1　。　あ！ 1 がでましたね・・・（^ - ^ )
4.Ａさんがファイル２に書き出し。　　　　　　　　　　　　　ファイル２のデータは１になる
5.Ｂさんがファイル１を読んだ。152　　　　　　　　　　　　ファイル１のデータは152
6.Ｂさんがファイル２を読んだ。1　　　　　　　　　　　　　　ファイル２のデータは1
7.Ｂさんのカウントは　153 　復旧
8.Ｂさんがファイル２に書き出し。　　　　　　　　　　　　　　ファイル２のデータは153
：

そして、カウンターが破壊される場合の流れは上記の1.の処理の前にファイル１が
すでに壊れていた場合です。
：
0.Ｙさんがファイル１に書き出し失敗。　　　　　　　　　　ファイル１が壊れた
1.Ａさんがファイル１を読んだ。　　　　　　　　　　　　　　ファイル１が壊れている
2.Ａさんがファイル２を読もうとしたが、よめなかった。　ファイル２のデータは151
3.Ａさんのカウントは　1　。 　あ！ 1 がでましたね・・・（^ - ^ )
4.Ａさんがファイル２に書き出し。　　　　　　　　　　　　　ファイル２のデータは１になる
5.Ｂさんがファイル１を読んだ。　　　　　　　　　　　　　　ファイル１が壊れている
6.Ｂさんがファイル２を読んだ。1　　　　　　　　　　　　　　ファイル２のデータは1
7.Ｂさんのカウントは　2 壊れた・・・
8.Ｂさんがファイル２に書き出し。　　　　　　　　　　　　　　ファイル２のデータは2
：
：
私が考えられたのは、上記のパターンだけですが、多分ほかにもあるでしょう。

話は変わりますが、rename　処理の件ですが。この命令を使えば、カウンター
は確かに壊れない様に思えます。でも、「とほほさん」のページには
「壊れにくくなる」との記述があります。どのような場合にこわれるのでしょうか。
ずっと気になっているのです。
http://wakusei.cplaza.ne.jp/twn/wwwcgi8.htm
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・・・
皆様、長々とお付き合いいただき、本当にありがとうございました。

そして伝説へ…

＞63 のらさん
>>46
>３ではありません。なぜわかるのですか？

3-san wrote: count_logディレクトリ内のファイルの数を数える方式

IPとagentなどを記録した新規ファイルをcount_logディレクトリにtimeか何かを
元にしたファイル名で書き出してcount_logディレクトリ内のファイル数を数える
方式だったら、43で33624個あったファイルが1個になっちゃったことになるでしょ?

ところで、この板は http://tako.2ch.net/test/read.cgi?bbs=perl&key=959378033 のような
話の持ちかけ方のほうがいい感じになるよ。知っていても、もう一度読んでみて。

MSゴシックはやめようよ…

>78
素朴な疑問。

1.Ａさんがファイル１を読もうとしたが、よめなかった。　ファイル１のデータは152
2.Ａさんがファイル２を読もうとしたが、よめなかった。　ファイル２のデータは151
3.Ａさんのカウントは　1　。　あ！ 1 がでましたね・・・（^ - ^ )
4.Ａさんがファイル２に書き出し。　　　　　　　　　　　　　ファイル２のデータは１になる
*5.Ｂさんがファイル１を読もうとしたが、よめなかった。　ファイル１のデータは152

この続きはどうなるんですか？

ファイル２が読めた場合はファイル１に２が書き込まれ、
読めなかった場合はファイル２に１が書き込まれる。

>85
どっちにしても壊れるのね。
ダメじゃん（藁

つか、カウンターだけを考えるなら読み込んだ時
ファイルサイズが0でなくなるまで書き込むのを待って
読み込みつづければとばなくない？

ファイル1個よりは2個の方が安全
ファイル2個よりは3個の方が安全
　　・・・
ファイルn個よりはn+1個の方が安全

どれだけファイルを増やしても完璧にはならないし
増やせば増やすだけ処理に時間がかかると思います。
その辺、どーなのよ？>1

ファイル１は152のままだから、次で正しく読み込めれば直るよ。

>89

>ファイル２が読めた場合はファイル１に２が書き込まれ

ファイル1は変更されるじゃん。

＞次で正しく読み込めれば直るよ。
ファイル２の読み込みに失敗した場合のみ。
成功したときは壊れます。

で、、、、
どこらへんが
「ファイルロックしなくても絶対に壊れないカウンター」
なんですか？(汗)

と言うか、
「ファイルが壊れてもある程度修復してくれるカウンター」
だね。

＞「絶対に壊れない」といういい方は　11　で「壊れにくい」に訂正しています。
きちんと読んであげなさいよ。
いいじゃん　みんな色々やりながら覚えていくんだし

結論：ちゃんとロックしましょう。

こんなんどう？（藁
1アクセスにつき、毎回、10個くらいカウンタプログラム起動して
多数決とる

>93、94
このあたりは自作自演でしょうか？(ﾜﾗ

#! /usr/bin/perl -w

open DAT＠｀ ">> count.dat" or die;
print DAT "x";

print "Content-Type: text/plain\n\n";
print -s DAT＠｀ "\n";

__END__

という作戦なのかと思ったわ。
やたらとディスク容量を食うという問題はある。

40＠｀87の方法もいいであろうが、ロックがやっぱり標準じゃろ。

じゃあ俺が壊れないカウンタの作り方を教えてやろう

"カウント.xxx"ってぐあいにファイル名にカウンタを持つんだ
そして"カウント+1.xxx"にrenameする
これに成功したらそれをカウンタ値として扱う！これだけ
OSに依存するかもしれないが、同時に処理されてもどちらかしか成功しない
失敗した方は頭に戻って再挑戦だ！

当然負荷がかかれば、いつまでもカウント値を採れない不幸者がいるので
これだけでは使えないけどな
まあ結局カウンタとロックファイルを共有しているようなもんだ

87も98も100も既出(ガイシュツではない(ﾜﾗ)
ログ読め

尻ツボミな結末のためsageの刑ですね

こうしよう

壊れたらカウンターがあったところに
猪木の画像と
「壊したら直せこのやろう、だぁ!」
という説明と、書き込みフォームと、サブミットが現れる。
そして自分の好きな番号を入力してカウンター復旧。

　 Λ＿Λ 　 ／￣￣￣￣￣￣￣￣￣￣
　（　´∀｀）＜ つまらんモナ
　（　　　　） │
　｜ ｜　|　　＼＿＿＿＿＿＿＿＿＿＿
　（_＿）＿）

103以降はネタスレッドになりました

御茶義理作った人もこんなカウンタ作ってなかったっけ？
でも知らずに作ったんならそれなりに立派だよ。
もっと早く生まれればよかったね。

先人を越える!これが後に生まれて来た者の使命です。

１さん、レスしてよー
それとも名無しさんで自作自演？

レスしなさいよ〜

これは壊れる確率（つーか、上書きオープン中に読み込んでしまう）
確率を1/2にしただけだろ？
で、あれば、テンポラリーファイルを介すやり方は、
同じ考え方で、確率は1/∞になる。
もっともリネームで衝突する可能性はあるが、
どこかで衝突する可能性があるのは、複数プロセスで
動かす以上、避けられない。
（ロックしてもロックが衝突する可能性もある）
結局、どんな方法でも、アトミックであることが保証されるまでの
わずかな隙を、いかに埋められるかって事と、最悪、衝突した場合に、
ファイルを壊さない仕組みを作ることが”出来ること”の全てだろう。
flockも、flockをコールしてから、実際にロックされるまでに
わずかな隙はあるが、symlinkを使う方法よりかは、隙は少ない。（と思う）
まぁ、この手の議論は数値化して効果を測ることが難しいから、
何度も沸いて来るんだろうけど、考え方は上で書いたとおり。
あとは、好きずきじゃない？
個人的には、flockを信用するべきだと思う。
カウンターだけの用途なら、renameしてカウントする方式も
良いと思うけど。
長々失礼。

「実際にロックされるまでのわずかな隙」ってなんだ（笑）
隙間はこれっぽっちもないです。
OSと排他制御について勉強してください…。

「この、このプロセスの間の、このホンの一瞬！　そう無限に拡大すればここに隙間が！」
ＣＰＵがクロック単位で動いてるのを思い出しましょう。

112がもし私宛であれば、mutexの実装について(できればアセンブラレベルで)
勉強してください…。Free UNIXのソースを見るとか、タンネンバウム先生のMINIXの
御本を読むとか。
110宛なら失礼。

>>111
> 「実際にロックされるまでのわずかな隙」ってなんだ（笑）
ファイルオープンの処理が終了してからflockの処理が開始するまでの隙だと思いますが。

例（あくまで極端な例ね。）：
open(FILE＠｀'>data.txt');
sleep(100);# ここで100秒間の隙が生じる
flock(2＠｀FILE);

１１０についていえば、「flockをコールしてから…実際にロックされるまでに」と書いてるです。

>115
んだんだ

CGIの作者のためのOS/コンピュータ科学の手軽な読本が必要とされている
気がしました。1はもはや電波の域だから丁重に保存するとしても、
その1を喝破できるだけの知識すらない人が、2chに限らず多過ぎます。

HTML(ていうか、HP(笑))作成の延長でCGIに足を踏み入れ、OSや言語や
通信についての理解もないままイカれたスクリプトを量産するのみならず、
よせばいいのにCGI解説ページまで作っちゃって嘘と誤解を拡大再生産する構図は
見ていて痛々しい。

とはいっても、正しい知識を、初心者に過不足なく伝えるのは、とても難しいですけどね。
自分ももっと修行しないと、知らないうちに嘘を拡大再生産する側に回りそうで恐い。
でも、2chは嘘書いても自分の信用に傷つかないからとても楽…。

＞117
一人ではりきってるトコ悪いんだけど、
あんたウザイ。

118=110?

＞119
なぜそうなる。
どういう思考回路持ってんだ。

open(OUT＠｀ "+< text.txt");
flock(OUT＠｀ 2);
　#これだとオープンしてからロックまでの隙が無い。
　#open(OUT＠｀ ">text.txt")を使うとロックまでにファイルサイズを０にしてしまうからマズイ。
　#open(OUT＠｀ ">text.txt")はファイルを読み書きモードで開くのでファイルサイズは変わらん。

truncate(OUT＠｀ 0);
seek(OUT＠｀ 0＠｀ 0);
　#読み書きモードで開いた場合はそのまま書くと上書きにはならないのでファイルサイズを０にする。

print OUT qq(書き出し);
　#ファイルへ書き出し

close(OUT);
　#ハンドルを閉じる。flockはクローズと同時に解除されるので特別に閉じる必要は無いというか、むしろロックが甘くなる。


以上がおそらく正しいflock関数の使い方。このロック方法で２０人程度が入室するウェブチャットCGIのログが飛んだことはない。
このロック方法に変える前のシムリンクを使った方法では結構ログ飛びしたけど。

open(OUT＠｀ ">text.txt");
flock(OUT＠｀ 2);

flock関数を上記のように使っている例があるけど、これは完璧に間違っているというか、隙がありすぎ。こんなものロックじゃない！！

年寄りとjapuは大切にした方がよいぞ。ふぉっふぉっふぉ。

あんたがスレ立てて解説してくれ。
途中で飽きたら辞めて良いから。

ファイルロックの使い方はそれで間違ってないけど、
理解は間違ってます。精進精進…

自分はエロ同人だから、夏コミ前は忙しいんですよ。あいすみません。

>124
私は121の人とは違うんですが
どこが間違っているんですか？教えて下さい。

use Fcntl;
sysopen(FH＠｀$file＠｀O_WRONLY|O_CREAT|O_EXLOCK);

>111
>「実際にロックされるまでのわずかな隙」ってなんだ（笑）
>隙間はこれっぽっちもないです。
perlのflockは、プラットフォームが提供するロック機能（flock(2)＠｀fcntl(2)＠｀lockf(3)）を
コールするだけです。
その意味を考えてみましょう。

>OSと排他制御について勉強してください…。
その前に物理学勉強して下さい。

電波野郎は黙ってろ

はうー。
system callを呼び出すまでの期間はcritical sectionには含まれない、とか
言っても、あなたにはわけわかんないですよね。でも他にうまく説明できないです…。
物理学じゃなくって国語をもう少し勉強することにします…

lockもrenameでやればいいのよ。
0.hoge→1.hoge でlock
1.hoge→0.hoge でunlock

うん蓄は良いから、現実的な方法論を語ってくれ。
言葉で納得させることができない奴はエンジニア失格だな。
よって、111=引き篭もりエンジニア決定。
そういう意味では、1以下。
国語より、他人とふれあう事から始めてくれよ。

皆さん、これいかがでしょう。
http://www.interq.or.jp/white/nora/cgi-bin/nobreakcounter.cgi164161.txt
>91ファイル２の読み込みに失敗した場合のみ。
>成功したときは壊れます。
この発言がヒントになっています。ありがとうございます。

111の言ってる事が正しければflockは安心して使えるって
ことになって方法論も何も結論出てると思うのだが？

OSの排他制御は物理レベルでは隙があるってこと？
初耳なので詳しい説明お願い。

普通のOSはｼｽﾃﾑｺｰﾙが呼ばれたとき特権ﾓｰﾄﾞになるが
この時割り込みが禁止されているわけでもなく、
またｶﾚﾝﾄCPU以外を排他しているわけでもない。
そのような制御がされているのは本当にｸﾘﾃｨｶﾙな部分である。
よってｼｽﾃﾑｺｰﾙ中に割り込みがかかる事もあるし、
別なﾌﾟﾛｾｽが同時に同じｼｽﾃﾑｺｰﾙを処理することもあり、
ｼｽﾃﾑｺｰﾙを呼び出したからといって排他制御されていると
思いこむのは危険である。

ああっ、なんてレベルが高いスレッドなんだ。これじゃ誰もついていけない。
２ちゃんねるも捨てたもんじゃないな。まだこんなレベルが高いスレッドが
あるんだもんな。しかし、ここに書き込んでいる連中は相当なレベルの高さ
だよなぁ。これじゃ、こんなにレスがつくのも当たり前だよ。本当に１の
レベルは高いと思うけど、それについて行ける奴も凄いな。まったく尊敬
するよ。おれもみんなを見習ってレベルの高い人間になれるように精進する。

そして、みんなについて行けるような立派なレス職人になるよ。まだ見習い
だけど３ヶ月後の俺を見ていてくれよ。みんなをアッと言わせるレス職人に
なるからさ。その時まで、みんなもレベルが高いのを持続してくれよな。
ほんと、２ちゃんねるに来て幸せだよ、オレは幸せものだなぁ。

半角カナやめれ
オタクくせえぞ

あの・・・さらにこうしたら精度もあがるんじゃないかと・・・

http://www.interq.or.jp/white/nora/cgi-bin/nobreakcounter.cgi164162.txt

ロックファイルが残ってしまうという症状があるんですが、
一定の時間がたったロックファイルを自動的に削除するというのは
できるんでしょうか？

ロックする前に、ロックファイルが残ってたらタイムスタンプ
見て古かったら強制的に消去。

>139
73を実装したんですね。

まぁ、もともと「読めなかったら読み直す(リトライ2回)」と
大して変わらなかったのですがねぇ。
(「読めなかったら読み直す(リトライ2回)」と比べて
壊れた方を復旧する作業がある分、優れてないと思われる)

タイムスタンプのチェックの構文の例があると
有り難いです。
すいません。

unlink ($lock_file) if (time - (-M $lock_file) > $lock_term and -e $lock_file);
とか？
でも、最初にチェックするより、
何度かリトライさせて、最後にロック外し忘れとして、
削除した方が良いと思うよ。

上の間違い、、、
-M　は日にちで返すのね。

>142
ちょっと誤解があるようです。
少し時間を下さい。もったいぶっているわけではありません。
整理したいので。

すいません。もうちょっと時間下さい。
それと、ご注意なんですが。公開したソースをＷＩＮＤＯＷＳ上で動かして、
テストしていただいている方も、中には、いらっしゃるかもしれませんが
ループ回数を極端にあげて、実行するのはくれぐれも止めてください。
１万回程度なら大丈夫（保証はしません）と思うのですが、私が今
回数百万回にして、実行してみたところ、マシンがフリーズしてしまいました。
やはり、相当な付加がかかるようです。改めて、>35　さんの忠告の大切さを
思い知らされました。>35　さん本当にありがとうございました。

参考までに、カウンターは大丈夫でした。

遅くなりました。申し訳ありません。長文になるかと思いますがよろしくお付き合い下さい。
>139 　73を実装したんですね。
そうです。その通りです。

>壊れた方を復旧する作業がある
この部分に誤解があります。これまで、掲示板にテスト結果の書き込みがあったように、
>8340 8341 8342 8343 8344 8348 8350 8352 8353 1
>あ！ 1 がでましたね。何かいいことがあるかも知れません（＾-＾）
>8357 8359 8360 8361 8362 8363 8365 8367 8370 8373 8373 8377 8377 8380 8381 8381 8383 1
こわれたカウンターは確かに「復旧」していますが、それは復旧作業をしたのではなく、「自動的に復旧した」のです。
このプログラム処理において、通常のカウントアップ処理と、1　が表示されたあとのカウントアップ処理はなんら変わり
がありません。全く同じ処理です。ロジックを見ていただければわかります。私が、1 で最初に述べたように、
>・セーブファイルにも同時に書き出しておいて、壊れたら、そこから復旧。
ではないのです。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　...続く

このプログラム処理の最大の特徴はなんと言っても、「ツインファイル」にあります。念のために付
け加えると、一個が「テンポラリーファイル」ではなく、「メインファイル」が２個です。
覚えていらっしゃるでしょうか？わたしは、17 で以下のような発言をしました。

>ファイルが壊れるときというのは、突き詰めていけば、この処理が
>根本的な原因だと思うのですが、どう思われますか？
>つまり上書きで書き出すために、ファイルをオープンしたときに
>クリアされてしまう。この後にデータを書き込むまでのわずかな間に
>ジョブがこけてしまったり、他の人が読み込み処理をおこなってしまったら、
>もうアウトですよね？違いますか？
>open(OUT＠｀ "> $file_cnt");

>クリアされてしまう。この後にデータを書き込むまでのわずかな間に
「他の人がデータを読み込んでしまう」のを防ぐために行うのがロック処理だと思います。
ジョブがこけてしまったら、もう防ぎようがない。確立を抑えるのが精一杯ならば、いっその
事、壊れるなら壊れていいじゃないか。データファイルはもう一個あるんだから。と言うことです。
だから、復旧作業を行う必要は、ありません。　　　　　　　　　　　　　　　　　　　　・・・続く

ここで気になるのが、「壊れるのが１個だったらまだいいが、２個壊れたらだめじゃん」と言うこと
です。ごもっともです。だから２個同時に壊れない工夫をしてあります。
Ｐｅｒｌを読めるかたは、ソースを見ていただきたいのですが、Ｐｅｒｌ以外の言語専門の方もいらっしゃるでしょうから以下の書き方をします。

ＩＦ　ファイル１のカウント数　＜　ファイル２のカウント数
　　ファイル１に書き込み
ＥＬＳＥ
　　ファイル２に書き込み。

つまり両方のデータを読んで値の小さいほうに書き込む。同じ値なら、２に書き込む。
もし、一方のデータが壊れていたなら、壊れているほうに上書きされます。これが
さっきの148で述べた、「自動的に復旧」です。72でヒントとして述べた　「よむ　よむ　かく」　です。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・・続く

カウンタファイルを複数にするというみんなが一度は思いつくであろう
シンプルなアイデアをここまで語れるのらに乾杯。

タスク1 ファイル1に書き込み開始
タスク3 ファイル1読み込み失敗
タスク4 ファイル1読み込み失敗
タスク1 ファイル1に書き込み完了
タスク2 ファイル2に書き込み開始
タスク3 ファイル2読み込み失敗
タスク2 ファイル2に書き込み完了
タスク3 ファイル2に壊れたデータを書き込み開始
タスク3 ファイル2に壊れたデータを書き込み完了
タスク4 ファイル2の壊れたデータを読み込み（カウンタ値 1）
タスク4 ファイル1に壊れたデータ書き込み
カウンタ1、2壊れる。

絶対壊れないと最初に見得をきった割には平凡すぎる
アルゴリズムなんで誰も当てられなかった。
クイズは君の勝利だ。よかったね。＞のら

>150
もちろん「復旧」は「自動的に復旧」の意味です。
(復旧作業をするのは人でなくプログラム)

　ファイル1の読み込みに失敗 かつ ファイル2の読み込みに失敗
　それでもその値(1かな？)を(値の小さいほうの)ファイルに書き込む。
　そして次のアクセスでファイルを復旧。

これって無駄じゃないかい？
「ファイル1の読み込みに失敗 かつ ファイル2の読み込みに失敗」
を判定して、これが真ならファイルに書かなきゃいいんです。
間違った情報を書き込まなければ復旧の必要もありません。

「絶対壊れない」
これが「偽」なのでクイズも糞もない。
「真」ならクイズも答え甲斐があったであろう。

>152
ファイル1個より2個のほうがマシってことでしょ。
(↑これは認めます。>1)
「flockよりファイルn個のほうがマシ」
これを満たすnは存在するのか？
処理のオーダーを考慮にいれると
どう考えてもflockのほうがマシと思うけど。

低レベルな争い、見てて笑える。(ピュア）

馬鹿発見(ミュア)
低レベルなのはア・ナ・タ♪

これで、
open(OUT＠｀ "> $outfile"); #ファイルをオープンして、クリア
print (OUT "$cnt\n");　　#書き出し
close (OUT);　　　　　　　　#クローズ

によるファイルの破壊は防げると思いました。防ぐというより、一個壊れちゃっても次のカウントアップ処理で両方読んで、大きいほうに１をたして、小さいほうに足しこむから、自動復旧。
両方読めなかったとしても、一時的に 1 が表示されて、片方が壊れるだけだから大丈夫。
この時点で私は「絶対に壊れない」と大きな勘違いをしました。

しかし、壊れることはありました。原因は意外なことに書き込み処理ではなく、読み込み処理にあっ
たのです。だから 17 でこんな質問をしたのです。

>open(IN＠｀"$file_cnt");
>$cnt = <IN>;
>close(IN);
>普通の読み込みの処理ですが、この処理に異常が起きる確立って
>どのぐらいなのでしょうか？ ...続く

>154
>「ファイル1の読み込みに失敗 かつ ファイル2の読み込みに失敗」
>を判定して、これが真ならファイルに書かなきゃいいんです。

全くその通りです。これを実装したのが、ソース 133 139　です。
ご覧下さい。　　　　　　　　　　　　　　　　　　・・・続く

160の続き

>91
>ファイル２の読み込みに失敗した場合のみ。
>成功したときは壊れます。
前にも述べましたが、この発言が大きなヒントになりました。

「成功したときは壊れる」

なんか変ですよね。読み込みに成功したんなら正常なデータが手元にあるはすです。
ＩＦ分で切り分けて、壊れるのを回避するのは、たやすい、わざわざ壊すことはないわけです。
91 さん感謝します。それと、この発言のもとになった　84　さんにも感謝します。

>142
>まぁ、もともと「読めなかったら読み直す(リトライ2回)」と
>大して変わらなかったのですがねぇ。

さっき言い忘れましたが、ここにも誤解があるような気がします。
リトライ２回の処理というのは、こういう処理でしょうか。

1.ファイルＡを読む
2.読めなかった-＞1に戻る（２回まで）
3.読めたら（または２回だめだったら）次の処理へ
4.ファイルＡに書き込み

この場合、3.の処理で、正常に読み込めたとしても、4.でこけちゃったら、ファイルは壊れます。
壊れたら、おしまい。
壊れても、大丈夫。
この違いです。

>153 155 156
ちょっと待ってください。まだ話は終わっていません。最後まで聞いていただけませんか。
もしも、それがいやなら、133　139　のソースを見てください。　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・・・続く

>4.でこけちゃったら
どういうときにこけるの？
CGIにおけるファイルのロックと何の関係が？

>152
>タスク1 ファイル1に書き込み開始
>タスク3 ファイル1読み込み失敗
>タスク4 ファイル1読み込み失敗
>タスク1 ファイル1に書き込み完了　　 　　　　　　　　　　　　　　※
>タスク2 ファイル2に書き込み開始
>タスク3 ファイル2読み込み失敗
>タスク2 ファイル2に書き込み完了 　　　　　　　　　　　　　　　　※
>タスク3 ファイル2に壊れたデータを書き込み開始
>タスク3 ファイル2に壊れたデータを書き込み完了　　　　　　　　※
>タスク4 ファイル2の壊れたデータを読み込み（カウンタ値 1）
>タスク4 ファイル1に壊れたデータ書き込み 　　　　　　　　　　　※
>カウンタ1、2壊れる。

よく分かりませんが、さっきも述べたように壊れたデータは書き込まないように回避できます。
最も単純なロジックだと、こんな感じでしょうか。

初期値を１にセットしておく。
ファイルＡを読む

ＩＦ　データ　＞　0　　　　　　　#正常なデータだったら
　　　　カウントに 1 をプラス
　　　　ファイルＡに書き込む　　・・・※
ＥＬＳＥ
　　　　　何もしない。

多分　73　さんのおっしゃりたいことはこういうことなんじゃないかとあとで思ったのですが、
違っていたらすいません。
このロジックも完全ではないと思います。※でこける可能性があるからです。
だから、149 で述べたように
「確立を抑えるのが精一杯ならば、いっその
事、壊れるなら壊れていいじゃないか。データファイルはもう一個あるんだから。」です。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・・・続く

ソースの履歴です。
78 http://www.interq.or.jp/white/nora/cgi-bin/nobreakcounter.cgi-sss640145.txt
133 http://www.interq.or.jp/white/nora/cgi-bin/nobreakcounter.cgi164161.txt
139 http://www.interq.or.jp/white/nora/cgi-bin/nobreakcounter.cgi164162.txt
最新 http://www.interq.or.jp/white/nora/cgi-bin/nobreakcounter3.cgi1646160707.txt

あ、でもまだ話は終わっていません。
まだ続きます。

データファイルがたくさんあっても壊れる可能性はある。
確率的にflockの方がまし。

＞のらさん

１.どういうときにファイルが壊れるか(パターンをあげる)
２.そのうちどのパターンがCGIにおいて最も深刻な問題か(頻発するか)
３.flockはどのように機能しているか(共有ロック、排他ロックの意味わかってますか？)

これらをちゃんと理解した上で
「ロックしないでファイルを(なるべく)壊れないようにする方法」
を語らないと。

まだ話の途中なんですが、お願いがあります。
昨日の夜私がソースを公開したあと、以下のように書き込みがありました。

>84
>1.Ａさんがファイル１を読もうとしたが、よめなかった。　ファイル１のデータは152
>2.Ａさんがファイル２を読もうとしたが、よめなかった。　ファイル２のデータは151
>3.Ａさんのカウントは　1　。　あ！ 1 がでましたね・・・（^ - ^ )
>4.Ａさんがファイル２に書き出し。　　　　　　　　　　　　　ファイル２のデータは１になる
>*5.Ｂさんがファイル１を読もうとしたが、よめなかった。　ファイル１のデータは152
>
>この続きはどうなるんですか？

これを見て、ああなるほど。と思ったのです。自分が気づかなかった欠点をご指摘いただいている。
その後 91 さんの発言を経て、ソースに改良を加えることができたのです。 31〜33　でも述べまし
たが、

「既存の処理にとらわれすぎているのでは ないでしょうか。」
「これだけのプロの方々が集まって、あれやこれや議論する中で、
新しい発想が生まれたならそれはそれですごいことではないてすか。
たとえ、ネタであったとしても、十分収穫のあったスレッドという
ことになるはずです。」

どうか、もっと前向きな発言をしていただけないでしょうか。私の希望としては、164 にアップした、
最新のソースを見ていただきたいと思います。そして、「やっぱり、こういう場合は壊れるじゃん」
「こういうパターンも壊れるね」という例をあげていただきたいのです。そして、それならこうしたら、
どうだ？という議論をしていただきたいと思うのです。だめでしょうか？

>166　88
私は今の段階では、ファイルは２個で十分だと思っています。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・・・続く

＞それならこうしたら
ロック
■■■■■■■　終了　■■■■■■■■

>167
あ、すいません。167 さんを読む前に書き込んじゃいました。
レスは、ちょっとお待ちください。

このスレッドは
ある個人のために
みんなでデバッグするスレッドなのだろうか・・・

指摘されるのを待ってないで自分でなんとかできないか

レベルの高い議論なら議論する価値がありますが
これではただのデバッグです。
議論する価値もありません。
もう結論は出てるでしょ。何回も、いろいろな方が言ってますね。
「ファイルを何個にしても根本的な解決策にはなりません」

ロックというものがなんのためにあるのか
勉強してから出直してください。

のらさんは、これを作りなさい。きっと尊敬されます。
http://tako.2ch.net/test/read.cgi?bbs=perl&key=962987129

ははは。その通り。俺はデバッグしてやっただけ。
条件網羅ってやつかな？

それはやばいって(爆)
匿名串のくせにIP漏れそう(爆)
しかもデバッグはCGI板の住人に任される・・・

あぶろーん

174を完成させてみてはどうか、のらさん。
君は一生、他人に自分用のオナニーCGIをデバックさせるつもりか。
他人のためのCGIも作ってみろ。
174のデバックには協力するつもりだ。
君の才能をぶつけてみなさい。

>176

のらくんはそんなへまはやらないだろう。
カウンターは壊れると思うが。

そうですか。それは失礼。
ちゃんと匿名串になってるならカウンタくらい壊れてもいいですよ。
むしろ壊れたほうがいいかも（ﾜﾗ

　

おや？

>どうか、もっと前向きな発言をしていただけないでしょうか。私の希望としては、164 にアップした、
>最新のソースを見ていただきたいと思います。そして、「やっぱり、こういう場合は壊れるじゃん」
>「こういうパターンも壊れるね」という例をあげていただきたいのです。そして、それならこうしたら、
>どうだ？という議論をしていただきたいと思うのです。だめでしょうか？

議論するまでもなく、ロックするのが一番いい
今までいくどとなく議論されてる話題。
アトミックな処理じゃない時点で終了。

>173
>もう結論は出てるでしょ。何回も、いろいろな方が言ってますね。
>「ファイルを何個にしても根本的な解決策にはなりません」

168 の最後に私は、
「私は今の段階では、ファイルは２個で十分だと思っています。」
と発言しました。とりあえず、そのことについて述べたいと思います。
このロジックでは、１回の処理において、１回の書き込みしか行わないのですから、
ファイルが２個同時に壊れるためには、
「１個がその前の処理ですでに壊れていて、1個は正常なデータのとき」に
「正常なデータの側に、壊れたデータが書き込まれる、または、書き込みに失敗する。」
ことが必要になります。
例えばこういう場合です。
ファイル１のデータ　-＞　1　　　　　　　壊れている
ファイル２のデータ　-＞　152　　　　　　正常
ファイルの書き込み条件は

ＩＦ データ　> 2
ＩＦ　　ファイル１　< ファイル２
　 ファイル１に書き込み
　　ＥＬＳＥ
ファイル２に書き込み
ＥＮＤ

読み込みのパターンとしては、
1.両方読めた
2.両方失敗
3.ファイル１は読めた、ファイル２は失敗
4.ファイル１は失敗、ファイル２は読めた.
この４つです。　　　　　　　　　　　　　　　　　　　　　　　　　　　・・・続く

1.の場合、
ファイル１に 153 が書き込まれる。書き込みに失敗したとしてもファイル２は正常のまま。
2.の場合、
書き込み処理は行われない。のでファイル２は正常のまま。
3.の場合、
書き込み処理は行われない。のでファイル２は正常のまま。
※ソース78では、このときファイル２は壊れます。ソース133では回避しました。
4.の場合、
ファイル１に 153 が書き込まれる。書き込みに失敗したとしてもファイル２は正常のまま。

さらに
ファイル１のデータ -> 152
ファイル２のデータ -> 1

の場合も壊れないと思います。
>84 さん　いかがですか？　　　　　　　　　　　　　　　　　　　　...続く

>167
大変遅くなって申し訳ありません。
1.　と　2.　についてはこのスレッドのログを読んでいただければ私なりの考え方がわかっていただ
けるのではないかと思います。3.については今の段階で私の低レベルな知識を並べ立てたところで、
反論の嵐で横道にそれてしまいそうです。>32　で述べた様に私は初心者です。専門知識はあなたの方が数段上に決まっています。
ロックの処理を使用した上でロックの事を知らない。というのなら、話は別ですが、少なくとも今の
段階では、私はロック処理を使用していません。 ...続く

最後になりますが。

これまでの、話を単純にまとめてみると、
1.ファイルを２個用意する。両方を「メインファイル」として扱い、両方よんで大きいほうが
最新のカウンター値である。
2.ファイルが２個あるので、どちらか１個だけならいくら壊れても構わない。
3.ファイルが２個とも壊れてしまうのをロジックで回避している。
4.どちらかのファイル、または両方のファイルの読み込みエラーがあっても、壊れたデータは
書き込まれない。
5.ロック処理は行っていない。

以上のことから、私は今の段階で、「非常に壊れにくいカウンター」になっていると思います。
ん？「絶対に壊れないカウンター」じゃないのか？というかたは、ログをお読みいただけると
助かります。
私の言う「非常に壊れにくい」というレベルがどの程度なのか、ロック処理と比べてどうなのか
判断は難しいところだと思いますが、今のレベルの私には断言することはできません。

上記の1〜5の根拠は？とおっしゃる方は、148〜の私のログを読んでいただけますでしょうか。
それが「めんどくさい」という方は、
最新 http://www.interq.or.jp/white/nora/cgi-bin/nobreakcounter3.cgi1646160707.txt
のソースのロジックを追いかけていただくか、window上の環境で、動かしてみてください。
その際は、かならず　147　の注意書きをお読みください。

とりあえず148 からの一連の話はこれで終わりにしたいと思います。
ありがとうございました。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　...終わり

じゃ、critical sectionの話はここで続けてもいい?

そんなやり方するなら、わざわざ代わる代わる書き出す必要ないじゃん。

open(FILE＠｀ "+< $file");
$cnt = <FILE>;
if($cnt++){
truncate(FILE＠｀ 0);
seek(FILE＠｀ 0＠｀ 0);
print FILE "$cnt";
}
close(FILE);
__END__

これで充分なんじゃないの？

open(FILE＠｀ "+< $file");
$cnt = <FILE>;
if($cnt){
$cnt++;
truncate(FILE＠｀ 0);
seek(FILE＠｀ 0＠｀ 0);
print FILE "$cnt";
}
close(FILE);
__END__

こうじゃないの？

＞189
そうでした。
訂正ありがとう。

一つのファイルだと、書き込み中にプロセスが不正終了したりサーバが落ちたりすると、データが飛ぶ可能性はあるな。
二つのファイルから読んでもしカウント数が違ってたら、大きい方の数字を両方に書き出すようにした方がより安全。
どっちにしても交互に書く必要はないわな。
つーか、カウンタにしか使えない似非ロック考えるより、素直にロックしようや。

ロックしたら
書き込み中にプロセスが不正終了したりサーバが落ちても
データは飛ばないの？

やっぱりあやしいわーるど掲示板に組み込まれている
「壊れにくいカウンター」が一番だな。
いまとなっては寂しいもんだがが、最盛期は一秒に
いくつもの書き込みが集中してたし。
ROMのりロードを含めるとものすごいアクセスだった。
その状況にも耐えたカウンタだから、モノがちがうよ。

>188 189
188さん、189さんへの私の意見は 191 さんと同じです。
>191
二つのファイルから読んでもしカウント数が違ってたら、大きい方の数字を両方に書き出すようにした方がより安全。
なるほどそういう考え方もあると思います。ただ、レスポンスの問題と、
なにより、一回の処理で両方のファイルに書き出したとき、両方ともトラブルがおきた場合、
両方いっぺんに壊れてしまうと思うのですが、いかがでしょう。
>つーか、カウンタにしか使えない似非ロック考えるより、素直にロックしようや。
この事に関してはそのうちに言われるだろうと思っていました。
「どこでも標準的につかわれていて、実績もあるのだから素直に使えばいいじゃん。
なんでそんなに「ロックしない」事にこだわるんだ？」という気持ちですよね。
　　　　　　　　　　　　　　　　　・・続く

続くのか…

>1
ごまかさないでちゃんと167に答えなさい。

「似非ロック」なんていうほどのものじゃない。
これはただのバックアップ。
強制終了したときに自動復元するM$ WORDのようですね(ﾌﾟ

そこまで心配するなら
$SIG{'TERM'} でなんとかフォローする。

カウンターの話になるといつもあやしいワールドのカウンタ
賞賛する書き込みが出るけど、どんなアルゴリズムなの？

管理人が手動で書いてる（ﾜﾗ

>194
「なぜロックしない」にこだわるのか。
ロックしない事にこだわっているわけではありません。今の段階ではまだあえて
ロックする必要がないと思うのです．79　と　84　で壊れることが発覚したときに
「じゃあどうすればもっとよくなるかなあ」と考えました。最初に考えたのはやはり
ロックです。幸いな事に、異常の原因は「読みこみ」のみ（発覚したのは）だったので
読みこみ処理にロックをかければ、少しはましになるかなと考えました。そして、ロック
中だったら、リトライでル‐プして・・・などど考えました。そしたら、91　さんの発言
です。読み込んだデータを判断して、異常なデータは書かなければいいじゃないか。
という発想で、ロック処理がまた先送りになっただけです。　　　　...続く

「レスポンスの問題とデータ破壊の危険性」ということを考えてみました。
まず、レスポンスのことを考えるなら、いらない処理は一個でも少ない方が良いに
決まっています。ロック処理がデータ破壊を防ぐ為の手段ならば、ロックしなくても
壊れにくいのなら、ロックしない方が良いに決まっていると思います。
でも「お前の処理もファイルを一個余分に読み込むという余計な処理をいれているじゃ
ないか。」というと思います。う〜ん、それを言われるとちょっとつらいところなのですが。
じゃあ、「データ破壊の危険性」を考えてみた時はどうでしょう。
ロック処理自体がデータを壊す危険性も有る？？し、ロックをクリアして、うまく読みこめた
としても、今度は書きこみ時の危険性があります。
それに対し、このファイル２個の方式は、まずロックしない、とにかくデータを読めようが
読めまいが、とりあえず読みに行く、そして読みこみを抜けてきた時点でデータを判断
して、不正なら書かない。正常なら、書きに行く。さらに、書きこみは一個のファイルに
対してしか行ないませんから、書きこみ時に異常があっても最悪でも一個しかこわれな
い。ということです。

改めて申し上げますが、ロック処理を使いたくないのではなく、今のところ使う必要が
ないのです。　84　さんのようにそれでも壊れる場合があれば、ロック処理を改めて
勉強しなおして、ロックを組みこむことを考えなければいけないのかも知れません。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　とりあえず終わりです。

単にカウントするだけだったらこのスレでいくつも出てるように
いくらでも強固なものがあるのに、なんでいつまでも複数ファイル
方式にこだわる？＞のら
しかも目新しいアイデアでもなんでもないんだよ。

やっぱアクセスログ(ホスト名とか時刻とかリファラーとか）とりたい
場合等の汎用性考えれば素直にロックするのを覚えておくのがベストで
しょう。

>201
すいません、ちょっと勘違いがあるみたいですね。読みこみ処理のみ
ロック。変ですね。

>204
のらです。あわててかいたので。・・すいません。

っていうかー意味ねーじゃん、これ。（藁
一人でやってろ

なんかとても恥ずかしいスレッドになってきましたね。

＞としても、今度は書きこみ時の危険性があります。
排他制御とはなんの関係もない。
書き込み中に電源が落ちたら？とか
書き込み中にHDがクラッシュしたら？とか
書き込み中にハルマゲドンが起こったら？とか
そういうレベルの議論がしたいのか、こいつは。
そんなにバックアップがとりたきゃ
1回ずつデータを自分宛てにメールするがよかろう。

132に「1以下」といわれたのがすごい堪えたから、
110への解説を別スレに書いてみたよ…。
http://tako.2ch.net/test/read.cgi?bbs=perl&key=963036704

今日のところは、これでお収めください…。

カウンターなんか、飛んだって別に問題ないじゃん。（笑）
たかがカウンターに、データーファイルを"2個も"使い必要なし。
flockを使えば済む問題では？
flockよりも、のらさんの言ってる方法が良いとは思えませんが？
flockの使えない環境で使えってことですか？（笑）
203さんが言ってるようにこの方法は汎用性に欠けると思うのですが。
いくら、新しい方法（このれは別に新しくもないけど）を考えても、
汎用性に欠けてる時点でダメなのでは？
カウンター以外に使い道ないし。
強固なロック処理がいる場合は、flockの方が断然すぐれてると思うのですが？

どうせなら、このスレで
完璧なロック処理を考えません？

どうせやるなら、別スレ立てましょう。

open (READ＠｀"log") or die "read error";
@readfile = <READ>;
close READ;

if ($readfile[0]){
++$readfile[0];
}else{
die "log road error"
}

if (-e "unlock"){
rename "unlock"＠｀"lock";
open (FILE＠｀">$log") or die "log write open error";
select FILE;
print $readfile;
close FILE;
rename "lock"＠｀"unlock";
}else{
die "now locking";
}

一般的だろ？>212

212:
ロックになっていません。

＞210
堅い汎用ロックを考えるんだったら、これ参考になるかも。
http://tako.2ch.net/test/read.cgi?bbs=perl&key=959378033&st=56&to=56
http://tako.2ch.net/test/read.cgi?bbs=perl&key=961217263

＞211
賛成。1も来なくなったことだし、この電波スレッドはもういい。

＞212
むちゃくちゃだ・・・

>212
きもい

> カウンターの話になるといつもあやしいワールドのカウンタ
> 賞賛する書き込みが出るけど、どんなアルゴリズムなの？

壊れにくさレベルの数だけカウントファイルを作り、
それぞれのファイルの数値を読み込み、その中で最も大きかった値に１を足して
もっとも小さい値が書いてあるファイルにその値を書き込むという方式。

Cのソースであらわすとこんな感じ。

http://perls.virtualave.net/test/src/list.cgi?main.c

あやしいわーるど掲示板のソース(最新のもの)はここ

http://kuzuha.tripod.co.jp/

1がやりたかったのはこれ？

「壊れにくさレベル」とはよくいったもので、確かに壊れ「にくい」。
通常の運用なら壊れないはず。
でも、正しくカウントされないことはあるでしょう。
実行効率も悪いし、まさにぁゃιぃ風味。

馬鹿？

>218 1がやりたかったのはこれ？
その通りです。217さんありがとうございました。

おいおい。。。

あ゛

結局1はただのバカに決定。

sub countup {
#read
　my $count;
　open IN＠｀ "$log_file" or die "cannot read log file";
　flock IN＠｀ 4;
　seek IN＠｀ 0＠｀ 0;
　$count = <IN>;
　close IN;
#write temp file
　my $success = 0;
　my $tmp_file = "$log_file\.$$";
　open TMP＠｀ ">$tmp_file" or dir "cannot create temporary file";
　print TMP ++$count;
　close TMP;
#write log file
　foreach (1..5) {
　　if (symlink '.'＠｀ $lock_file) {
　　　unlink "$log_file\.bak" if (-e "$log_file\.bak");
　　　rename $log_file＠｀ "$log_file\.bak";
　　　rename $tmp_file＠｀ $log_file;
　　　$success = 1;
　　　unlink $lock_file and last;
　　} else {
　　　sleep 1;
　　}
　}
　if ($success) {return 1;}
　 else {return 0;}
}

>224
全然ロックになってないです。

>224
あなたそれ間違ってます

>224
もう結論出てるよ。

symlink 失敗したら、tmpが溜まっていくね（藁

デバッグスレッド・・・

ごめん、sage忘れた・・・

>225＠｀226
どの辺を直したらロックになります？

>227
すいません、ちょっと付き合ってあげてくださいm(__)m

>228
最後の return 0 の前に、unlink $lock_file すればいいかな？

死ね

>224
ログ全部読めや。
それでもわからなかったら諦めろ。

初心者とそれに群がる厨房達

>233
ログ読んで、224を書いたんです
どこが間違ってるか指摘してもらえませんか？

初心者とそれに群がる厨房達
・・・と指摘されると途端に書き込みをやめる厨房達

>235
どの辺を直すとか以前に全然ダメです。
224がログを読んで書いたものだなんてネタとしか思えません。

ＷＩＮＰｅｒｌだと、FLOCK　も　sysopen　も　SYMLINKも使えないから
ロック作りにくいです

>238
WINPerlは使ったことないんだけど、mkdirもダメ？

対処法を考えましょう。
まず、使っているperlとOSの正確な名称とバージョンを書いてください。
WINPerlではなんだかさっぱりわかりません。

>235
ここで聞くのが間違い
しったか君の煽りとアホーのマジレスしかつかないんだから（藁

まず最初に、CGI解説のWebページを読んで得た知識は、全て忘れてください。
symlinkもrenameも一時ファイルも、全部。

次に、CGIのことは無視して、必要な機能を実現する一番単純なスクリプトを書いてください。
コマンドラインからperl foo.pl と叩いたときに、ちゃんと動作すればよいものを。

次に、そのスクリプトを頭の中で、複数個並列に動かしてみてください。
いろいろな状況を想定してみて、
並列に実行してはいけない処理は、どの部分の処理かを、見極めてください。

最後に、その処理をファイルロックで囲ってください。
flockだけで十分です。

mentai落ちてる？
ping通らないよ。

flockが使えない場合の・・・あ゛、読み込みでflock使ってました、、、。
すいません、出直します。

相互排除にflockを使うのは、本質ではありません。
rename等を使うロック手法に比べて、効率が良く安全である、というだけの違いです。
224のスクリプトは本質的に、だめです。

>224
ここ逝け。3日で解決するらしいぞ。
【Perl】 初心者コーナー
http://tako.2ch.net/test/read.cgi?bbs=perl&key=957208980

カウンターごときにもういいだろ。

よし、ロックしなくても絶対100％壊れないカウンターを教えてやろう。
サーバのアクセスログを常にチェックしながらアクセスがあるごとに自分でindex.htmlを書き換えるんだ。
これでいいだろ。＞1

専用サーバ持ってる場合だったら、
�@CGIは常駐processとソケット通信するだけ。
�A常駐processは子プロ起動などせずシリアルに処理を行う。
で絶対壊れないわけだから、こういう話自体あんまり価値ないと
思うんだけど。

>>249
それいいねえ。ためしにカウンタでも作ってみるかー。
あ、BBSでもいけるかな？　まあ２ｃｈみたいな規模だと、
待ち行列のサイズが膨大になりそうでこわいけどね。

カウンタのプロセスに、カウントデータの保持されているメモリを
共有させりゃぁいいわけじゃん？ロックはメモリの特定アドレスの
値が０ならカウント可で１なら待ち、これで絶対に壊れない。
簡単簡単♪

>251
０かどうかをチェックして１にする操作がアトミックにできんのか？

アセンブラなんか知らなくてもいいってのが話題になったりするけど
こういう話がでてくると ちっとぐらい知っとけって思う

>252
そこまでシビアに考える必要あんの？

>254
問題あるの分かっててロックするんだったらPerlのopen関数でロックして
安心してるやつらと「ある意味」同レベルのような気がする。

>254
この程度でシビアなのか（TT
普通のことじゃん（TT

根本的に操作が違いますが、
open(OUT＠｀">> $file")
の時は、
OPEN(OUT＠｀"> $file")
より壊れにくいのでしょうか？

>>265
普通だね。

このスレ楽しすぎなのでage

>254
シビアつーか、ここまでつーか (ワラ
これを考えなければ排他制御にならないし、これ以上考える事は無い。

補足
フラグのリード・モディファイ・ライトをアトミックに行う事が全て。

>>260
それ、可能ですか？

>259
そこまで考えているカウンタが何％あるだろう・・・。

http://www.maido3click.com/2ch/
これは? どのへんまで正確?
所詮カウンタなんてそんなもんでしょ、

とりあえず、壊れてはいないんじゃない。

> 261
不可能ならば非同期割り込みどうやって制御するんだ?
x86なら一番下ではBTS＠｀BTRとかのtest & set使ってるんだろうな。

>>265
割り込みと >>261 って関係あるの？
割り込みは特殊なんじゃないの？
運悪く、読込、の後に別プロセスに順番が変わってしまうって
ことがあるような気もするけど、どうなんだろう。

はい、史郎とです。

> 266
関係ある。
リード・モディファイ・ライトをアトミックに行う事すなわちセマフォ
これが出来なきゃ、処理がどこまで進んでいるかなど全く考えずに上がってくる
非同期割り込み処理できるわけ無い。
スミソミアン展示してあるようなものなら出来なくても不思議は無いが、
近代的なコンピュータとは言えない。

> 運悪く、読込、の後に別プロセスに順番が変わってしまうって
だから、そんなことが100%起こらないようにする機構が用意されてる。
BTS＠｀BTRはビット テスト&(リ)セットで命令実行中は割り込まれない。
この命令が無かった286の頃は割り込み禁止してたが、割り込み禁止
には特権が必要なんで、ユーザプログラムでは無理。

「並行プログラミングの原理 啓学出版」でも読んで勉強しなさい。

質問です。ファイルが飛ぶ場合の症状ですが、ファイルサイズが
0になる以外のパターンってあるのでしょうか？
今までの経験ではファイルが書き換わったり、ファイルそのものが
消滅したことは一回もないのですが・・・
ほとんど大多数の場合は中身がなくなると考えてもいいのでしょうか？

> 268
おそらく
プロセスA リードオープン
プロセスA データリード
プロセスA クローズ
プロセスA ライトオープン
プロセスB リードオープン (ここでファイルは空)
....
プロセスB ライト
というパターンが多かっただけだろ。

OSはプロセスに指示されたとおりに書き込む、従ってファイルが消えることも無いし、
君の意思に反してティムポのサイズが書き込まれることも無い。

>269
ありがとう。
でも、まじめに読んでたので最終行の意味が一瞬わからなかった。
気づいて吹きだしてしまいました。家族が変に思ったことでしょう。
ともかくありがと。

＞だから、そんなことが100%起こらないようにする機構が用意されてる。
＞BTS＠｀BTRはビット テスト&(リ)セットで命令実行中は割り込まれない。

１．Ａがロックのフラグをメモリから読み込む
２．処理がＢの順番に移る
３．Ｂがロックのフラグをメモリから読み込む
４．Ｂがロックの可否を判断する→「更新可能」と出たと仮定
５．Ｂがカウンタの値を操作する→１０＋１＝１１
６．処理がＡの順番に移る
７．Ａがロックの可否を判断する→「更新可能」と出る
８．Ａがカウンタの値を操作する→１０＋１＝１１

そして値は結局＋１しかされない、ということはあり得る、
こういうことでしょうか？

>>271
全然違う気がする。考え直します。

１．Ａがロックのフラグをメモリから読み込む
２．Ａがロックの可否を判断する→「更新可能」と出たと仮定
３．Ａがカウンタの値１０を読みとる
４．処理がＢの順番に移る
５．Ｂがロックのフラグをメモリから読み込む
６．Ｂがロックの可否を判断する→「更新可能」と出る
７．Ｂがカウンタの値１０を読みとる
８．Ｂがカウンタの値を操作する→１０＋１＝１１
９．処理がＡの順番に移る
10．Ａがカウンタの値を操作する→１０＋１＝１１

そして値は結局＋１しかされない、ということはあり得る、
こういうことでしょうか？

>>273
これも違う。（藁

最後です。あたまがテンパってきました。

１．Ｂがロックのフラグをメモリから読み込む
２．処理がＡの順番に移る
３．Ａがロックのフラグをメモリから読み込む
４．Ａがロックの可否を判断する→「更新可能」と出たと仮定
５．Ａがフラグを「更新不可」に設定する
６．Ａがカウンタの値１０を読みとる
７．処理がＢの順番に移る
８．Ｂがロックの可否を判断する→「更新可能」と出る
９．Ｂがフラグを「更新不可」に設定する
10．Ｂがカウンタの値１０を読みとる
11．Ｂがカウンタの値を操作する→１０＋１＝１１
12．Ｂがフラグを「更新可能」に設定する
13．処理がＡの順番に移る
14．Ａがカウンタの値を操作する→１０＋１＝１１
15．Ａがフラグを「更新可能」に設定する

そして値は結局＋１しかされない、ということはあり得る、
こういうことでしょうか？

BTRはtest & resetをアトミックに行う。
従って、フラグを読み込み、テスト、フラグをリセット。ここまでが一気に実行される。
テストの結果は386の内部フラグ(具体的にはCF)にセットされる。

flagの初期値はオンとして
loop:
BTR flag
if(!CF){
リスケジューリングしても良くってよ♪
goto loop
}
クリティカルな処理
フラグをセット

つーことでマルチプログラミングを扱えると称している環境ならば
このような排他制御を行う機構がどこかに用意されている。
> そして値は結局＋１しかされない、ということはあり得る、
> こういうことでしょうか？
排他制御を正しく行えば、カウンタは正しく動く。

ついでに書いとくとマルチCPUな場合はLOCK BTRでバスロックして、
他のCPUからも保護すりゃいい。

ここら辺でも読んどいてくれ。
http://www.tokumaru.org/techterm/primitive.html

>>276
ほぉ・・・読込からテストまでを一気に実行してくれるんですかぁ。
説明ほんとありがとうございますぅ。リンク先も読んでみます。

http://www2q.biglobe.ne.jp/~terra/cgi/lockfile.htm
ここのはどうよ？
ロックしてるけどデータが壊れる事は無いぞ。

だいたいロックせずに壊れないデータ処理なんて
あるわけないやん（笑）

＞どこまで壊れないのか、検証していただけるとありがたいです。
検証ってどうやるの？？実際に処理がぶつかる確率って
普通にやったらほとんど無いよ。
サーバにも迷惑かけるし。

検証したいなら自分でプログラムして検証しろよ。
そんなことも出来ない奴が偉そうに書くな（藁）

>>278
いつの話だ、それ？
つか、そんな厨房ページ持ち出すなよ…。

>>279
http://tako.2ch.net/test/read.cgi?bbs=perl&key=971182903&st=61&to=61
ホント、どうしてこんな厨房サイトにいつまでも騙される奴がいるかね。
マジで迷惑だから消えてほしい、ここ。

> 278
そこは、厨房サイト。
理由は上でさんざん書かれている。

げっ
http://www2q.biglobe.ne.jp/~terra/
ここプロつーかソフトの販売もしてるぞ。

ユーザの方、ご愁傷様です。

がーん・・・だまされてた・・。
http://www2q.biglobe.ne.jp/~terra/cgi/lockfile.htm

結局、どんなロックが良いの？
より確実に、より高速に、より単純に、、。

誰かまとめて下さいな。

結局UNIXサーバだとflockじゃないの。
# 世の中にはflockの嘘っぽい解説も多いけど。

@niftyはSolarisのくせにflockが使い物にならない。

flockがまともに動くならflockだろうが、perlのflockは
それらしきシステムコールへのラッパーになってて、下で何
を呼び出してるか、信用できないところが痛い。

さらにlinuxでの実装が腐っていたとか、
http://www.qmail.org/man/man5/maildir.html
なんかもflockが嫌われる理由だな。

まとめ
実行環境選ばないという点を評価して
http://www.din.or.jp/~ohzaki/perl.htm#File_Lock

open(LOG＠｀ "+< $logfile") || die "Error";
eval 'flock(LOG＠｀ 2);
truncate(LOG＠｀ 0);
seek(LOG＠｀ 0＠｀ 0);
print LOG @DATA;
close(LOG);

これではだめなの？

>>288
何も考えずにevalするとflockに失敗していても気付かない可能性があって怖い。

>>287
| flockがまともに動くならflockだろうが、perlのflockは
| それらしきシステムコールへのラッパーになってて、下で何
| を呼び出してるか、信用できないところが痛い。

これ興味あるので詳しい説明か解説サイトのURLきぼーん。

>>288
このスレを読むとわかるけど、flockの戻り値チェックは
必須だそうです。
アクセスが多いところだと、リソース不足でflockが失敗する
可能性もあるから。

>>287
renameはNFS環境だとアトミック性が保証されないってホント?
http://tako.2ch.net/test/read.cgi?bbs=perl&key=971182903&st=71&to=71

カウンタを管理するためだけのデーモンがあれば解決すんじゃない？
自分で鯖立ててそういうサービス始めてみたら繁盛するかもよ？
儲からないだろうけど

>>292
http://tako.2ch.net/test/read.cgi?bbs=perl&key=971182903&st=84&to=84

デーモンもいいけどDB使ってロックの問題はDBにまかそう
カウンター管理専用にOracleを！

あとは、アクセスがあるたびに管理者にメールを送るようにして
管理者がそのメールを自分で勘定してカウンターファイルを
書き換えるとか

> 290
pp_sys.cのここいら。 コンフィギュレーションで呼び出すシステムコールが異なる。
#ifdef HAS_FLOCK
# define FLOCK flock
#else /* no flock() */

/* fcntl.h might not have been included＠｀ even if it exists＠｀ because
the current Configure only sets I_FCNTL if it's needed to pick up
the *_OK constants. Make sure it has been included before testing
the fcntl() locking constants. */
# if defined(HAS_FCNTL) && !defined(I_FCNTL)
# include <fcntl.h>
# endif

# if defined(HAS_FCNTL) && defined(F_SETLK) && defined (F_SETLKW)
# define FLOCK fcntl_emulate_flock
# define FCNTL_EMULATE_FLOCK
# else /* no flock() or fcntl(F_SETLK＠｀...) */
# ifdef HAS_LOCKF
# define FLOCK lockf_emulate_flock
# define LOCKF_EMULATE_FLOCK
# endif /* lockf */
# endif /* no flock() or fcntl(F_SETLK＠｀...) */

>>296
さーんきう。
flockが使えなければfcntl、それも使えなければlockfつう
わけですね。OSのシステムコールの実装も意識せないかんのか。
うちのサーバはFreeBSDだからflockはflock(2)そのものだ。

も一箇所気に入らないのがここ。fflushのエラーチェックしてない。
if (fp) {
(void)PerlIO_flush(fp);
value = (I32)(PerlLIO_flock(PerlIO_fileno(fp)＠｀ argtype) >= 0);
}
もともとperlはfflushのエラーチェックできないから、どうでもいいか。(藁

age

宣伝スレ＆駄質問スレにsageられてウザイので
age age age age age age

あげる時は、内容のあることかけ、このハゲ！

>301
お前もsageろよ、ｺﾞﾗｧ！

てめえぶっ殺すぞ。

>303
sageろよ、ｺﾞﾗｧ！

馬鹿か？

＞馬鹿か？
あなた思考回路が短絡過ぎるようです☆（藁

flockなんか使えねえよお・・・これで何度苦渋を味わってきたことか。
俺は簡単に扱えるrenameでいいや、と割り切ってる。
完璧とか絶対とかあんまり信じてないし。

完璧とか絶対じゃなくて、良いか駄目かだってば。

とほほカウンタとterraのアクセス統計の両方を使ってます。
パソコン内でテストすると、
とほほカウンタは処理があっという間なんだけど
terraのアクセス統計は2テンポ位処理が遅い。
んでterraはrenameだったからflockにしてみたけど変わらない。
何故だろう。

>>307
flockはサーバによってはマジで使えないね。それも使えるふりをするからいちばんたちが悪い。

>>309
遅い方でgethostbyaddrあたりが使われてたりしないか？

gethostbyaddr は遅いよね…。

あと、AnHTTPDでテストしてる時、うっかりZoneAlarmで
Perlに「ネットにアクセスさせない」設定にしてたら、5秒くらい
gethostbyaddrのところで動きが止まって焦った。

＞AnHTTPD
使っている奴がいるのか。ほっほう。
ついでにAnHTTPDでページ公開している奴はいるのかな？

両方とも使ってます
ちなみに遅い方はこんな感じです。

$QUERY_DATA = $ENV{'QUERY_STRING'};
$datacount = @DATA;
$hostadd = &host_get;

sub host_get {
　local($addr) = $ENV{'REMOTE_ADDR'};
　local($_) = gethostbyaddr(pack("C4"＠｀split(/\./＠｀$addr))＠｀2);
　if ($_ eq '') { $_ = $addr; }
　else {if (/.+\.(.+)\.(.+)\.(.+)$/) { $_ = "\*\.$1\.$2\.$3"; }
　elsif (/.+\.(.+)\.(.+)$/) { $_ = "\*\.$1\.$2"; }
　elsif (/.+\.(.+)$/) { $_ = "\*\.$1"; }
　else { $_ = "no"; }}
　$_;
}
$agent = $ENV{'HTTP_USER_AGENT'};
$agent =~ s/＠｀/./g;
if($agent eq ''){ $agent = "no"; }
$hreflink = $QUERY_DATA;
$value = "$date_now\＠｀$hostadd\＠｀$agent\＠｀$hreflink\＠｀$hour\＠｀$min\n";
while ($datacount >= $max) {
　pop(@DATA);
　$datacount = @DATA;
}
unshift(@DATA＠｀$value);
open(LOG＠｀ "+< $log_file") || die "Error";
eval 'flock(LOG＠｀ 2);';
truncate(LOG＠｀ 0);
seek(LOG＠｀ 0＠｀ 0);
print LOG @DATA;
close(LOG);

シンプルに考えよう

カウント＋＋は

open ( COUNT＠｀ ">>$countfile" );
print COUNT '0';


カウントリードは

-s $countfile;

これでいいだろ

訂正
カウント＋＋に
close COUNT;
も必要だね

これ以上のカウンタスクリプトはないだろう

>>315
禿しくがいしゅつ。

何がなんでもパールで組みたいんだねぇ
>>49 が出した答えでいいじゃん
あとは常駐プロセスを許す鯖を見つけることだな
俺の使ってる貸鯖は常駐プロセス不可だよ（そういうルールで借りてる）
誰か常駐プロセス許しててＴＥＬＮＥＴできる貸鯖教えてくれ

age

guest guest

>>320
相当ヒマ？

なんでtakoにだけこんなしつこく書き込むんだろ。
fusianasanでIPが出て自分のおバカぶりが披露されないから?

手コキじゃないだろ

>318
ここにいるヴァカどもはソケットとかプロセスとかって何のことか
わかんないんじゃないの？

>があるとしたら信じます？
あほか、氏ね。

>>342
激しく同意。

>>324
こういうやつに限って口ばっかりで何もできないんだよな。
とりあえずまともな「完成したプログラム」を書ける人間なら
そういう低能なことは言わないよ。
ソケットとかプロセスとか、単体では意味がない技術情報に詳しいだけだと見た。
ま、それすらハッタリの可能性も高いけど・・・
うまく組み合わせてプログラムに活かせなかったら単なる知識に過ぎない。
知識があるのを自慢したいだけなら別だけどね（ﾜﾗ

人格的な反論はともかく、技術的な反論は？

>知識があるのを自慢したいだけなら別だけどね（ﾜﾗ
ソケットとかプロセスとかって、自慢になるような『知識』なのか？

>>324
>人格的な反論はともかく、技術的な反論は？
あれだけの書き込みにどうやって技術的な反論をすればいいっての？
人格的によろしくないと思ったんで、そこを突っつきたかっただけだよ。
ただアラシじゃないんで一応sageるだけの良心は持ってる。
そんなとこ。

>ソケットとかプロセスとかって、自慢になるような『知識』なのか？
こういうのを「語るに落ちる」っていうんだよ。
自慢にならないような知識だと自分で認めているなら、あんな書き込みは
しないことだね。

でもこのスレの１にさあ、
『ファイルロックしなくても絶対に壊れないカウンターがあるとしたら信じます？』
って、書いてあって延々と議論が続いているから。

そういう物がこの世に存在しないと本気で信じている人がいたのか？って思ったんですけど。

>あれだけの書き込みにどうやって技術的な反論をすればいいっての？
いやだから、常駐プロセスでシリアルに処理すれば、壊れようがないだろ
って言ってるだけですけど。

>>324
常駐プロセスが許されない場合は？

というか自分はソケットとかプロセスとかには詳しくない。
だから技術的にどうこうという細かい反論はそもそもできません。スマソ。
ただ自分のプログラミングで必要になれば情報を集めて来るアテもあるし
プログラムに活かすことができる自信もある。
個人的にこのスレは（試行錯誤の過程が）面白いと思っていただけなので
１を見た瞬間にヴァカどもと決めつけられるような筋合いはない・・・ということ。

> 『ファイルロックしなくても絶対に壊れないカウンターがあるとしたら信じます？』
> って、書いてあって延々と議論が続いているから。
このスレは、何十万人いるかわからない先人が思いつかなかった画期的な方法
思いついてしまったと勘違いしたノラ君を笑いつつ、カウンタ、排他制御に
関してまたーりするスレなのです。

最近ふと思いついた。
同じファイルに書き込むからロックが必要なんだから
毎回カウント数のファイルを作ってしまえば
ロックがいらないのでは？

処理的には、フォルダ内のファイルを探す。
1.dat
を発見したので$countに1を代入
1.datを削除
$count++する
$count.datって名前のファイルを保存

ってな感じです。
どう思います？？だめ？？無駄？？

駄目

＞333
飛ばないけど、カウント数10%ｹﾞﾝしそうだﾈ

Ｗｉｎでも動くだろうし、新しいでしょ？
「ファイルロックしなくても絶対に壊れないカウンター」
ってのはコレでＯＫかな？

でも、やっぱ動作遅いのかな？？(謎)

1＠｀000＠｀000＠｀000 数えて、 1＠｀000＠｀000＠｀001 にする時を考えて味噌。
あくまでも例だよ、、、

>>338
・・ゴメンあんま頭良くないので・・・
解説きぼ〜ん。

>>337
ファイルが幾つかあるときは最大のものを取るようにすれば、
たまに1になっちゃう訪問者があることを除けば、壊れはしない…と思う。

ただ、その場合ゴミファイルが残るので、だんだん負荷が増える。
ゴミが残らないようにすると、消える可能性が出る。
正直、あんまり良くないかもしれない。

良く考えてみるとゴミが残るのはけっこう特殊な場合だけだから、問題にならないかなぁ。
使用状況によるかも。

あと、ファイルを保存したあとに削除するようにすると、
たまに1になるのが無くなるかなぁ。

案外面白いやり方とは思わない？
某のら君の案よりは、全然壊れないと・・・（笑）
まあ、カウンターのみにしか使えそうに無いけどね。

4で既出。

>>4？
・・あ確かに同じ種類・・。
でも４は、書き出し不要でリネームだから少し違うね。
まあ、意味的には同じかぁ。
リネームの方が良い感じもするし・・。

カウンタには、ファイル名を使ったやり方が
実は面白いとは思いません？駄目？
ロックで十分？？ハイすみませんでした・・。

Ｃ＋＋でもいいかい？
こないだちょっとバグ作りこんじゃった時の話なんだけど、
同じファイルを２重にストリーム（ofstream）でオープン
したら、最初の方のクローズを行うまで２番目のストリー
ムの出力に待ったがかかっていた（どちらの出力も少量）。
これってライブラリやＯＳに依存する？
もし依存しないならこれで壊れないカウンタでき
そうな気がするんだが。
まぁモノがバグなんで現象とか詳しく調べてないけどさ
っつーかそんな時間なかったし。
誰か実験してくれ
そして結果を教えてくれ
俺に楽をさせてくれ（藁

プログラム板に聞いてみては如何でしょう？☆

ofstreamのコンストラクタのお話。
vc++4のマニュアルコピペですが、

ofstream();
ofstream( const char* szName＠｀ int nMode = ios::out＠｀ int nProt = filebuf::openprot );
ofstream( filedesc fd );
ofstream( filedesc fd＠｀ char* pch＠｀ int nLength );

nProt ファイルの保護を指定します。デフォルトは、静的な整数 filebuf::openprot です。これは、filebuf::sh_compat と同義です。指定可能な nProt の値を以下に示します。
filebuf::sh_compat 互換共有モード
filebuf::sh_none 排他モード (共有しない)
filebuf::sh_read 読み込み共有許可モード
filebuf::sh_write 書き込み共有許可モード

内部でどういう共有管理をしているのか知らないので、
「壊れないカウンタ」に利用できるかは判りません☆

既出ですかね。

my $Retry = 1;
my $CountDir = 'count';

Count:
{
do{
opendir DIR＠｀ $CountDir or error( 'open_dir' );
( $count ) = grep /^\d+$/＠｀ readdir DIR;
closedir DIR;

error( 'no_count_file' ) if $count eq '';

if( rename "$CountDir/$count"＠｀ "$CountDir/".($count+1) ){
last Count;
}

} while $Retry-- > 0;

error( 'count' );
}

ディレクトリオープンが効率悪げかなぁ。

と思ったら4にあったよ。die

そんなにカウンターが壊れるとこまるのか？

懐かしいね。

ああ、懐かしいな

ＩＭＧタグで貼り付けられるカウンタースクリプトで
一番壊れにくいお薦めってあります？
ＫＥＮＴは速攻で壊れたんだけど・・・。
昨日と今日のアクセス数も表示できる奴で。

ここのカウンターが強いぞ。
http://www.skiple.com/counter/index.html

guest guest