use Fcntl qw(:DEFAULT :flock);
use SDBM_File;
use strict;
my $db = tie(%h, 'SDBM_File', 'filename', O_RDWR|O_CREAT, 0666)
   or die "Couldn't tie SDBM file 'filename': $!; aborting";
flock($db->fd, LOCK_EX);
#...
undef $db;
untie %h;
[download]

I once thought that was the correct way to lock an SDBM file, until someone pointed out that there's a timing window

    my $db = tie(%h, 'SDBM_File', 'filename', O_RDWR|O_CREAT, 0666)
       or die "Couldn't tie SDBM file 'filename': $!; aborting";
--> # right here
    flock($db->fd, LOCK_EX);
[download]

At first, you'd think this wasn't a hole. But opening an SDBM file (the last time I looked) actually causes some file I/O. So what happens in this window is that two processes have read some bookkeeping data from the file into memory, one process gets the lock and proceeds to do things that side effect bookkeeping, while the other process blocks. When the first process frees the lock, the second process unblocks, but has data in memory that is now inconsistent with what's on disk. Oops.

The way around this is to use a separate file for locking, and acquire the lock before opening the SDBM file.

I may be working off of stale info, though. Can someone who has access to SDBM source confirm that significant I/O happens when the file gets opened?

this code works on DB_FILE but not on SDBM_FILE

the code doesn't work period. Read Locking: The Trouble with fd in the DB_File documentation.