【100分】C#进程的怪事

Question

当然，可能有这样一个解释（这里p3延时为300毫秒）： 
当p3结束p1时，p2据上次延时已超过4700毫秒，所以它能赶在300毫秒（到时它本身会被结束）之内启动p1 
但如果是这样，p3不能结束p1,p2的概率只有6%（300/5000）
------------------------------------------
一看就有問題，實在不知道這6％是怎么計算的.
依LZ的邏輯，如果p3是延時5000秒，p3不能结束p1,p2的概率難道就是100%（5000/5000）了？？？

Answer 1

还有，如果在窗体的Load事件中写入代码，只有等这段代码执行完后，窗体才会被绘制出来 
怎么解决这个问题呢？
============================================================================
可以考虑用异步（新开线程）的方式来处理

Answer 2

不要用sleep();用Process.WaitForExit 试试~~~

Answer 3

回5楼：
p3如果延时过长，p2有足够的时间来启动p1，之后p2虽然会被结束，但那时p1会启动它，当然是100%不可能结束p1,p2了

Answer 4

花了一些时间，测了一下。结果如下：首先：ＬＺ的内部while 语句会导致ＣＰＵ资源全部占用，在单个ＣＰＵ的机器上会出现不确定的影响。因为，两个进程１００％抢占时，结果是不可确定的。我测试时在p1,p2内部中加了一个　１ＭＳ的小睡，其它代码相同 如下：
private   void   Form1_Load(object   sender,   EventArgs   e) 
                { 
                        while   (true) 
                        { 
                                System.Threading.Thread.Sleep(5000); 
                                while   (Process.GetProcessesByName( "p1 ").Length   >   0)   Ｔread.Sleep(1);                                 Process.Start( "p1 "); 
                        } 
                }结果：
例１：近乎１００％成功
ＫＩＬＬ一个进程在我的机器上需要 15ms - 16ms 的时间
启动一个进程在我的机器上需要 31ms - 78ms 的时间因此，在在ＫＩＬＬ一个进程后，p3有　＞　15ms的时间去ＫＩＬＬ另一个例２：近乎１００％不成功按照上面的例子，只要ＫＩＬＬ的快，就可以成功，但为什么这里不成功了呢？
原因就在ＬＺ的代码逻辑
假如启动p1　１０s之后，p3的ＳＬＥＥＰ时间设为 300
(５s后，p2被启动）1.此时p1,p2都在判断对方是否正常，
2.KIll p1
3.1 p2不需要等待启动p1，然后进入５０００的sleep
3.2 p3进入等待300
4. 300　后，kill p2
5. 5000-300后　p１启动p2其它情况就先不分析了。

Answer 5

我觉得是系统延时的问题,当你用P3关闭P1时回产生系统延时,而线程P3的休眠时间为300太小了容易是系统不稳定,你可以尝试将线程P3的修面时间设为3000试下

Answer 6

回15楼，感谢你的亲自测试
下面是我的回复：
1.加不加小睡结果都是一样的
2.启动或结束一个进程只需数十毫秒，相对于sleep的数百数千毫秒微不足道，完全可以忽略
3.5000-300后，p1启动p2？这是不可能的，因为p1早就被kill了另外，我通过加一些标记，发现顺序是：
p3结束p1
p2启动p1
p3结束p2
p1启动p2
这就怪了，p3只睡眠了300毫秒，p2则睡眠了0--5000毫秒（平均也有2500毫秒），它怎么能赶在自身被结束之前就去启动p1呢（要知道，发生这种情况的概率只有6%，但测试结果表明，近乎100%的情况下，它都能这样）不可思议

Answer 7

当Kill　p1后，p2立马就把p1启动了。
所以，(5000-300)时间后，当p2被Kill时，p1又把p2启动。

Answer 8

如果你想实现禁止任务管理器结束进程，你可以参看下这个地址，希望对你有帮助
C#的工程原代码和具体内容可以在以下连接看到。
http://blog.csdn.net/kangkanglx/archive/2010/06/25/5692984.aspx