[shell应用进阶]：限制同时运行脚本实例的个数 -- 串行化：换一个思路。

woodie

原帖由 waker 于 2006-10-12 09:28 发表
cat token_file | sed "s/\ $pid//" > token_file
在bash中仍然有可能会清空file

用ed吧

好建议！用ed应该比较保险，兼容性也很好。谢谢！

waker

>本来这个脚本要解决的问题就是高并发情况下可能发生的一些问题，高并发环境下，某些my-script的请求被拒绝是再正常不过的，这并不是世界末日。

这和之前r007的设计是一样的，只保证脚本不会多次运行，不保证脚本会运行，OK，这应该不是一个问题


>再说一次，token.sh是一个监控的模块，只需要运行一次
这点不敢苟同，没看到保证 token.sh正在运行而且唯一的任何操作，靠人脑计数么？

r2007

用token.sh来协调的方式是一个不错的方法。但是应该避免waker提到的出现同时运行的情况。
既然token.sh只是扮演一个协调员的角色，那么不必让用户接触到此脚本。
想法如下：
让token.sh只能由root执行，并且设置成开机运行。
普通用户，仅需要执行my-script脚本，两脚本之间通过管道通讯。
PS:就是不清楚不同用户的进程能否通过管道建立通讯。

waker

原帖由 r2007 于 2006-10-12 10:20 发表
PS:就是不清楚不同用户的进程能否通过管道建立通讯。

命名管道不就是为这个目的才产生的么？

cyaln

学习ing。。。。。。。。。。。。。。。虽然还不是很懂

awk就是awp加ak

16排，座位我占了

woodie

原帖由 waker 于 2006-10-12 10:08 发表
...
>再说一次，token.sh是一个监控的模块，只需要运行一次
这点不敢苟同，没看到保证 token.sh正在运行而且唯一的任何操作，靠人脑计数么？

人脑计数，有何不可？手指头加上脚趾头足够用了。^_^开个玩笑。
呵呵，有不同的看法很正常。That's why the forum for.
我的想法是token.sh的执行时机是用户高度可控的，执行的频率对一次并发任务的执行是惟一的 -- 即只在开始执行一次，因而不需要过多考虑并发的问题。
当然你和七兄的观点也是有道理的，我并没有拒绝这个建议，只是前面对七兄已经简单回答过了，只是没有深入地探讨细节 -- 以前的帖子已经讨论得太多了。^_^
woodie>...如要防止意外运行两次，可以在该脚本的开始检测一个标志，有则退出就行了...

waker

问题不是人脑不够用，而是人脑太多，如何保证用户A运行了token.sh而用户B不去运行token.sh?如何保证B用户不会kill掉token进程？
如果要保证，是不是又回到了问题的起点？

[ 本帖最后由 waker 于 2006-10-12 12:10 编辑 ]

網中人

呵. woodie 兄的 idea 不錯!
不過, 從 ethernet 的原理來看, 倒不像是 token ring, 反而像是 CSMA/CA .
也就是 request to send(RTS) 跟 clear to send(CTS) .

還是我理解錯了?

woodie

原帖由 waker 于 2006-10-12 12:09 发表
问题不是人脑不够用，而是人脑太多，如何保证用户A运行了token.sh而用户B不去运行token.sh?如何保证B用户不会kill掉token进程？
如果要保证，是不是又回到了问题的起点？[img]http://bbs.chinaunix.net/images/s ...

呵呵，说的不是一个问题。我的着眼点是特定的一个密集并发的任务，这时用户显然知道自己要做什么，没有可能傻到启动一大堆token.sh。
waker兄想的更远点，如果有多个不同的并发的任务 -- 不妨把它称为多个并发任务集，其中每一个的内部都面临多个进程并发执行的问题 -- 都要调用token.sh的情况。
OK，这个想法是对的，但考虑的焦点却错了。其实管理多个并发任务集的多个token.sh同时执行 -- 这件事情本身并不会造成问题，关键是它们用到的命名管道和令牌文件必须各不相同，那样的话运行多少个token.sh都没有问题。相互删除的问题如果是由token.sh自己来退出或者用进程号来标识的话也可以避免。
因为我的楼顶贴出的脚本还只是一个初步的原型，有很多需要完善的地方，现在还不能作为一个通用的工具来使用。请大家多提意见！^_^现在的命名管道名和令牌文件名还是硬编码的，如果要做的通用一些，可以考虑用参数或者配置文件的方式来设置。