Here are the pros and cons of the DBM file-locking wrappers available from CPAN:

Tie::DB_Lock
A DB_File wrapper that creates copies of the DBM file for read access, so that you have a kind of multiversioning concurrent read system. However, updates are still serial. After each update, the read-only copies of the DBM file are recreated. Use this wrapper in situations where reads may be very lengthy and therefore the write starvation problem may occur. On the other hand, if you have big DBM files, it may create a big load on the system if the updates are quite frequent. This module is discussed in the next section.

Tie::DB_FileLock
A DB_File wrapper that has the ability to lock and unlock the database while it is being used. Avoids the tie-before-flock problem by simply retying the database when you get or drop a lock. Because of the flexibility in dropping and reacquiring the lock in the middle of a session, this can be used in a system that will work with long updates and/or reads. Refer to the Tie::DB_FileLock manpage for more information.

DB_File::Lock
An extremely lightweight DB_File wrapper that simply flocks an external lock file before tying the database and drops the lock after untying. This allows you to use the same lock file for multiple databases to avoid deadlock problems, if desired. Use this for databases where updates and reads are quick, and simple flock( ) locking semantics are enough. Refer to the DB_File::Lock manpage for more information.

On some operating systems (FreeBSD, for example), it is possible to lock on tie:

tie my %t, 'DB_File', $DBM_FILE, O_RDWR | O_EXLOCK, 0664;

and release the lock only by untying the file. Check if the O_EXLOCK flag is available on your operating system before you try to use this method!