+Infine il campo \var{l\_pid} riporta (viene usato solo in lettura, quando si
+chiama \func{fcntl} con \macro{F\_GETLK}) qual'è il processo cui appartiene il
+file lock. Nella semantica POSIX infatti il comportamento dei lock è diverso
+rispetto a quanto visto in precedenza per \func{flock}. Lo schema della
+struttura usata in questo caso è riportato in \figref{fig:file_posix_lock};
+come si vede essa è molto simile a quanto visto in
+\figref{fig:file_flock_struct} per \func{flock}:\footnote{in questo caso si
+ sono evidenziati nella figura i campi di \var{file\_lock} significativi per
+ la semantica POSIX, in particolare adesso ciascun lock contiene, oltre al
+ \acr{pid} del processo in \var{fl\_pid}, la sezione di file che viene
+ bloccata grazie ai campi \var{fl\_start} e \var{fl\_end}. La struttura è
+ comunque la stessa, solo che in questo caso nel campo \var{fl\_flags} è
+ impostato il bit \macro{FL\_POSIX} ed il campo \var{fl\_file} non viene
+ usato.} il lock è sempre associato all'inode, solo che in questo caso la
+titolarità non viene identificata con il riferimento ad una voce nella file
+table, ma con il valore del \acr{pid} del processo.
+
+Tutto ciò significa che la rimozione di un blocco viene effettuata
+controllando che il \acr{pid} del processo richiedente corrisponda a quello
+contenuto nel lock. Questa diversa modalità ha delle conseguenze precise
+riguardo il comportamento dei lock POSIX. La prima conseguenza è che un lock
+POSIX non viene mai ereditato attraverso una \func{fork}, dato che il processo
+figlio avrà un \acr{pid} diverso, mentre passa indenne attraverso una
+\func{exec} in quanto il \acr{pid} resta lo stesso. Questo comporta che, al
+contrario di quanto avveniva con la semantica BSD, quando processo termina
+tutti i file lock da esso detenuti vengono immediatamente rilasciati.
+
+La seconda conseguenza è che qualunque file descriptor che faccia riferimento
+allo stesso file (che sia stato ottenuto con una \func{dup} o con una
+\func{open} non fa differenza) può essere usato per rimuovere un lock, dato
+che quello che conta è solo il \acr{pid} del processo. Da questo deriva una
+ulteriore sottile differenza di comportamento: dato che alla chiusura di un
+file i lock ad esso associati vengono rimossi, nella semantica POSIX basterà
+chiudere un file descriptor per cancellare tutti i lock realtivi al file cui
+esso faceva riferimento, anche se questi fossero stati creati usando altri
+file descriptor che restano aperti.
+
+Come abbiamo visto come l'interfaccia POSIX per il file locking sia molto più
+potente e flessibile di quella di BSD, ma è anche molto più complicata da
+usare, specie in tutti quei casi in cui non si vogliono bloccare sezioni
+separate di file. Per questo, seguendo System V, è disponibile una interfaccia
+semplificata grazie alla funzione \func{lockf}, il cui prototipo è:
+\begin{prototype}{sys/file.h}{int lockf(int fd, int cmd, off\_t len)}
+
+ Applica, controlla o rimuove un \textit{file lock} sul file \param{fd}.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\macro{EAGAIN}] Non è possibile acquisire il lock, e si è
+ selezionato \macro{LOCK\_NB}, oppure l'operazione è proibita perché il
+ file è mappato in memoria.
+ \item[\macro{ENOLCK}] Il sistema non ha le risorse per il locking: ci sono
+ troppi segmenti di lock aperti, si è esaurita la tabella dei lock.
+ \item[\macro{EDEADLK}] Si è riconosciuta una situazione di
+ \textit{deadlock}.
+ \end{errlist}
+ ed inoltre \macro{EBADF}, \macro{EINVAL}.
+ }
+\end{prototype}
+
+Il comportamento della funzione dipende dal valore dell'argomento \param{cmd}
+che specifica quale azione eseguire; i valori possibili sono riportati in