I am moderately appalled at the answers in this thread. So far nobody has pointed out that you should do as perlstyle says and put an error check on your open statement, and several people gave you answers with the mistake repeated. I really think that we as posters should be setting good examples here.

Secondly your loop variable is not declared with my. That is an excellent sign that you have not yet been introduced to strict.pm, which is another habit to point out since it will save you a lot of grief and debugging time in the future.

Thirdly you are not localizing your filehandle. Given that you are naming it something fairly generic, this habit may come back to haunt you in the future even though it is not bothering you now.

Fourth you don't show us what your lock function looks like. But if it is based on OS-level locks (eg flock) then as merlyn points out at Don't use unflock (flock 8). Ever., there is no need to unlock if you are about to close. In fact it is a good thing to be in the habit of not doing.

Fifth, you don't show us what your lock function looks like, but it is very important for it to have an error check. There are many configuration issues that can cause locking to stop working, and it is very hard to notice that before it hits production. This is a much more important detail than the error check on the open.

And finally, my experience suggests strongly that locking file access is the wrong thing to do. You want to lock entire logical operations, and what constitutes a logical operation is something that depends on your application. When people try to lock at a file operation level, their overall code tends to wind up with race conditions. Since most people have a very hard time seeing race conditions, this tends to lead to periodic and hard to track down bugs. See the thread starting at RE: Flock Subroutine for more on this.

Now I don't expect the average PerlMonk to come up with all of the items on this list. But I am disappointed that apparently nobody noticed any of them. :-(