linux – 这个规范的群集示例如何工作？
发布时间：2020-12-13 23:08:40 所属栏目：Linux 来源：网络整理
导读：当必须通过文件系统同步程序( shell脚本)时,我发现基于flock的解决方案是 recommended(也应该工作 on NFS).在脚本中使用的规范示例(从 http://linux.die.net/man/1/flock开始)是： (flock -s 200# ... commands executed under lock ...) 200/var/lock/myloc
|
当必须通过文件系统同步程序(
shell脚本)时,我发现基于flock的解决方案是
recommended(也应该工作
on NFS).在脚本中使用的规范示例(从
http://linux.die.net/man/1/flock开始)是：
( flock -s 200 # ... commands executed under lock ... ) 200>/var/lock/mylockfile 我不太明白为什么整个构造确保原子性.特别是,我想知道在例如何时执行flock -s 200和200> / var / lock / mylockfile的顺序. bash执行这些代码行.这个订单是保证/确定性的吗？我理解它的方式,如果这个成语应该起作用,那一定是确定性的.但是由于子进程是在子进程中生成的,所以我不明白这两个进程是如何同步的.我只看到这两个命令之间的竞争条件. 如果有人能让我对此消失感到困惑并解释为什么这个结构可以用来安全地同步进程,我将不胜感激. 同时,如果有人知道,我会感兴趣的是选择一些任意文件描述符(例如示例中的200)是多么安全,特别是在具有许多客户端的大型NFS文件系统的上下文中. 解决方法
在子shell中执行任何命令之前,必须评估子shell(…)200> / var / lock / mylockfile的整个I / O上下文 – 并完成I / O重定向,所以重定向总是在flock -s 200之前.考虑子shell是否将其标准输出传送到另一个命令;必须在创建子shell之前创建该管道.这同样适用于文件描述符200重定向.
文件描述符号的选择确实无关紧要 – 除了建议不要使用文件描述符0-2(标准输入,输出,错误).文件名很重要;不同的进程可以使用不同的文件描述符;只要名字达成一致,就应该没问题. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |