C#中AutoResetEvent的诡异行为

一.缘起

最近做一个服务端程序,系统运行时,在特定的时候会启动一个通知线程,通知线程执行的方法经简化后就是如下的FirstStateNotifyThread:.

    AutoResetEvent autoResetEvent = new AutoResetEvent(false);
    private void FirstStateNotifyThread()
    {
        this.logger.LogWithTime("进入通知线程");            
        if (this.autoResetEvent.WaitOne(this.timeoutInMsecs))
        {
            //......
        }
        else
        {
            //......
        }
    }

通知线程中用到了AutoResetEvent以等待某个事件完成以达到同步的目的。启动线程的方法如下:

   CbGeneric cb = new CbGeneric(this.FirstStateNotifyThread);
   cb.BeginInvoke(null, null);

开发、调试、测试、部署到自己的测试服务器 都一切运行正常。当部署到正式的服务器上运行时,发现需要启动线程的时刻到来时,没有出现“进入通知线程”的日志,即FirstStateNotifyThread方法没有被执行,线程没有被启动。

二.追踪

于是,我换了一种启动线程的方式,像下面这样:

   Thread thread = new Thread(new ThreadStart(this.FirstStateNotifyThread));
   thread.Start();

情况不仅依旧,而且当要启动线程时,整个进程异常退出了,弹出的提示框内容是“程序遇到问题,将被关闭”。

然后,我再换一种方式:

ThreadPool.QueueUserWorkItem(new WaitCallback(this.FirstStateNotifyThread1) ;

仍然一样,也导致进程退出。

郁闷了,并且只有这台服务器上才会出现,其也是windows 2003 server 系统,是怎么回事了?

接着,我把FirstStateNotifyThread 方法中的逻辑代码全部去掉,只留一句写日志的代码,结果,可以正常执行。就这样不断地增加业务代码,最后问题定位到了autoResetEvent.WaitOne方法,如果注释掉这一句,就OK,开启这一句,就导致执行FirstStateNotifyThread 的线程无法启动。

大概找到问题的位置后,我尝试使用AutoResetEvent的另一个WaitOne重载方法:

autoResetEvent.WaitOne(this.timeoutInMsecs ,false)

使用这个重载方法后,在正式的服务器上也可以顺利的启动FirstStateNotifyThread 线程了。

三.暂时的结论

问题看似解决了,但是问题的根源在哪里了?我用reflector查看了AutoResetEvent的WaitOne方法的源码,一起来看看:

[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]
public virtual bool WaitOne(int millisecondsTimeout)
{
    return this.WaitOne(millisecondsTimeout, false);
}

public virtual bool WaitOne(int millisecondsTimeout, bool exitContext)
{
    if (millisecondsTimeout < -1) throw new ArgumentOutOfRangeException("millisecondsTimeout", Environment.GetResourceString("ArgumentOutOfRange_NeedNonNegOrNegative1"));
    return this.WaitOne((long) millisecondsTimeout, exitContext);
}

第一个WaitOne方法直接调用了第二个重载的WaitOne方法,这没什么问题。焦点在于第一个WaitOne方法标记了TargetedPatchingOptOut这样一个Attribute,查询MSDN知道:TargetedPatchingOptOut是用于指示内联(inline),熟悉C或C++的朋友对这个词应该非常熟悉。根据前面的步步验证,可以肯定的是,在我们正式的服务器上要加载或执行内联了WaitOne的代码镜像时,出现了异常。至于是什么异常,代码中使用try/catch捕获不到。

之后,我又测试了ManualResetEvent,也存在同样的情况。问题的根源可能已经涉及到了CLR或windows程序执行,但还是可以总结一点经验:为了使ManualResetEvent/AutoResetEvent在所有的机器上都能正常运转,请使用带有两个参数的WaitOne方法。

四、讨论

NeedForSleep:

看一看那台服务器的.Net版本。一个参数的版本只支持 引用.NET Framework 受以下版本支持:4、3.5 SP1、3.0 SP2、2.0 SP2

.NET Framework Client Profile 受以下版本支持:4、3.5 SP1 所以,尽管是.Net 3.5,但你不打Sp1补丁,就没有这个方法。

Daniel Cai:

的确如此,之前碰到过TFS服务器上FRAMEWORK没升级导致服务器上无法编译2个参数的WAITONE方法。

—八戒—:

建议在你的通信项目里面还是不要使用ManualResetEvent/AutoResetEvent,这样会导致你的通信项目运行时的效率很低。。

Andy:

其实很大概率出现问题的原因是由于.net framework的版本问题导致的,就比如1楼说的那样子,生产环境中没有那个一个参数的方法,导致使用了,内部报错。我记得在WaitOne内部是利用线程来实现的,如果这个线程内发生异常,在外部是没有办法捕捉到的。