File locking (and resource locking in general) is only needed when resource contention is likely to happen and the resulting problems outweigh the problems you have by implementing the locking mechanism.

In your case, you only use top.html for reading in the code, and it seems to me like top.html is part of some search-result template. If this is the case, then top.html does not change often, and is written to only when somebody copies over a new version of it. The results of reading a half-written top.html would be that somebody gets a broken page, which is fixed by the moment they reload it. If all of that were the case, locking would be overhead that has no practical value, as people will see broken results because of bad connections more often anyway.

If you had a second CGI which updates top.html much more often (say every minute), your chance of producing broken HTML would increase. You could then still try to avoid locking with some fancy file renaming tricks. But the risk of getting a lock conflict because one script tries to write and the other tries to read from the half-written file is still there and you're heading into lock-land.

The case where you will absolutely need locking is, when you have two (or more) scripts (or two instances of the same script) that try to write to the same file at the same time. In this case you will always need locking.

perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ;    # The  
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new   #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' #  web
[download]