Chiama flock(2), o una sua emulazione, su FILEHANDLE. Restituisce vero in caso di successo, falso in caso di fallimento. Produce un errore bloccante se usato su un calcolatore che non implementa flock(2), il lock di fcntl(2) oppure lockf(3). flock è l'interfaccia portabile del Perl al lock dei file, sebbene esegua dei lock solo su interi file e non su record.

Due semantiche di flock potenzialmente non ovvie ma tradizionali sono che esso aspetta indefinitamente fino a che il lock non sia assegnato e che i suoi lock sono solamente consultivi. Tali lock discrezionali sono molto flessibili ma offrono minori garanzie. Questo significa che i programmi che non usano anch'essi flock possono modificare quei file sottoposti a lock con flock. Per i dettagli consultate perlport, la vostra specifica documentazione sul port oppure le vostre manpage, specifiche del sistema. Se state scrivendo programmi portabili, è meglio che assumiate un comportamento tradizionale. (Ma se non lo state facendo, dovreste sempre sentirvi perfettamente liberi di scrivere per le vostre idiosincrasie del sistema (chiamate talvolta "caratteristiche"). Pedisseque aderenze agli interessi della portabilità non dovrebbero intralciare nel portare il lavoro a termine).

OPERAZIONE è una di queste: LOCK_SH, LOCK_EX o LOCK_UN, combinate eventualmente con LOCK_NB. Queste costanti sono tradizionalmente i valori 1, 2, 8 e 4, ma potete usare i nomi simbolici se li importate dal modulo Fcntl, sia indivudualmente sia come gruppo, usando il tag ':flock'. LOCK_SH richiede un lock condiviso, LOCK_EX richiede un lock esclusivo e LOCK_UN rilascia un lock richiesto precedentemente. Se su LOCK_NB viene effettuato un or a livello di bit con LOCK_SH o LOCK_EX, allora flock terminerà immediatamente piuttosto che bloccare aspettando il lock (controllate lo stato di ritorno per vedere se lo avete ottenuto).

Per evitare la possibilità di una non coordinazione, ora il Perl svuota FILEHANDLE prima di effettuare un lock o un unlock su di esso.

Va notato che l'emulazione insita in lockf(3) non fornisce lock condivisi e richiede che FILEHANDLE sia aperto per scopi di scrittura. Queste sono le semantiche che lockf(3) implementa. Tuttavia, molti se non tutti i sistemi implementano lockf(3) in termini del lock di fcntl(2), dunque le differenti semantiche non dovrebbero infastidire troppe persone.

Va notato che l'emulazione fcntl(2) di flock83) richiede che FILEHANLDE sia aperto per scopi di lettura per usare LOCK_SH e richiede che sia aperto per scopi di scrittura per usare LOCK_EX.

Va notato anche che alcune versioni di flock non possono effettuare lock su oggetti in rete; per questo caso sarebbe necessario usiaste fcntl che è più specificatamente orientata al sistema. Se preferite, potete forzare il Perl ad ignorare la vostra funzione flock(2) di sistema, e dunque fornire la vostra emulazione basata su fcntl(2), passando l'opzione -Ud_flock al programma Configure quando si configura perl.

Ecco un un programma che aggiunge mail al file mailbox per sistemi BSD.

    use Fcntl ':flock'; # importa le costanti LOCK_*

    sub lock {
	flock(MBOX,LOCK_EX);
	# e, nel caso che qualcuno abbia aggiunto
	# mentre si era in attesa...
	seek(MBOX, 0, 2);
    }

    sub unlock {
	flock(MBOX,LOCK_UN);
    }

    open(MBOX, ">>/usr/spool/mail/$ENV{'USER'}")
	    or die "Impossibile aprire mailbox: $!";

    lock();
    print MBOX $mess,"\n\n";
    unlock();

Su sistemi che supportano un vero flock(), i lock sono ereditati attraverso le chiamate fork(), mentre quelli che devono ricorrere alla pià capricciosa funzione fcntl(), perdono i lock, rendendo pià difficoltoso lo scrivere server.

Consultate anche DB_File per altri esempi su flock().