目标是"锁定"对串行设备或其他Linux设备的访问，以确保在设备中使用该设备的独家访问。例如，这样可以防止两个程序打开相同的串行设备和"竞争"以从设备读取字节。
建议是使用SYSV风格的UUCP设备锁定文件，例如/var/lock/LCK..ttyS1。这就是Linux Serial Hotwo推荐的：锁定其他人。它也在文件系统继承结构标准中进行了记录。它是由GTKTERM，PICOCOM等串行终端程序实施的。有一些库，例如liblockdev和liblockfile来支持这一点（尽管这两个库之间的实现细节有所不同）。
但是，我发现了Debian Bug＃734086，它在Linux上说，SYSV风格的UUCP设备锁已弃用，并且应该使用flock()咨询锁。
但是，我找不到可靠的文档来源来描述这些SYSV风格的UUCP设备锁的贬值，以及flock()的建议，除了Debian Bug本身。
我还找到了screen实用程序使用的ioctl(fd, TIOCEXCL)锁定终端。
哪种现代的"最佳实践"用于锁定Linux中的串行端口和其他设备？我们在哪里可以找到描述这一点的最新文档？
据我所知，使用串行端口或其他设备的flock(fd, LOCK_EX | LOCK_NB)锁定可能是Debian在Debian Bug＃734086中的领导之后，可能是Linux的最佳选择。请注意，这次Debian变革的原始拥护者Roger Leigh已于2014/2015年从Debian和Linux转移到FreeBSD上（请参阅此处的评论）。但是Debian似乎坚持使用flock()方法，所以值得一提。
但是，鉴于此时已将此更改传达给了更广泛的Linux社区，因此支持较旧的SYSV风格的UUCP设备锁定文件（/var/lock/LCK..ttyS1）作为编译时间选项可能是一件好事仍在使用较旧的锁定方法。
例如。Picocom现在已更改为使用flock()方法，并使用编译时选择SYSV风格的UUCP设备锁定文件。
Stackoverflow上的另一个答案描述了两种方法：
-
ioctl(fd, TIOCEXCL) -
flock(fd, LOCK_EX | LOCK_NB)方法
它说"一个应用程序可以选择做一个，或者两者"，进一步解释：
使用两者的原因是检测其他过程是否已经打开了该设备而不将其放入独家模式，但有望设置咨询锁。在这种情况下，
open()和ioctl()都成功了，但是flock()失败了。
所以，值得另外实施ioctl(fd, TIOCEXCL)。