CheckForIllegalCrossThreadCalls和control.Invoke有什么不同

      1.目的： 窗体的创建或者load方法中加入 Control.CheckForIllegalCrossThreadCalls =false; 就可以跨线程调用了。

      

      2. 那什么是跨线程？？

     eg:主界面Form是一个线程,如果你使用Thread开了另外一个线程 childThread,那么在childThread里你是不能直接调用Form里面的控件的

      3.为什么不允许跨线程？

      按理说不考虑访问数据的安全性，我们在多线程的程序中， 如果两个线程同时去访问一个内存地址的数据（当然是有读取和写操作），

      如果我写到一半，你就读取走了。读取者就会得到无效的数据，这样常常导致致命错误，这样就需要同步。

      而C#的界面UI线程也是线程安全的，他要求只有创建UI线程才可以修改UI数据，否则就会出现线程不安全的因素。如果你想修改数据，你可以把你        调用函数，放到线程池中调度的，UI线程有空就会调用的

      4.必须要使用怎么办？？

      CheckForIllegalCrossThreadCalls和control.Invoke有什么不同，哪个更好用，更高效呢？

        占在任何角度讲，都不要使用CheckForIllegalCrossThreadCalls，即便他运行和代码编写的确实比Invoke效率高 。 
        感兴趣的，可以参考我后面贴出的代码来测试对比一下两者的不同。这里我只简单说一下结论：
        1、性能CheckForIllegalCrossThreadCalls=false时比invoke高，而且代码比较优雅。
        测试时间如下：
        Button1 ---------------------------
        00:00:01.0760900
        00:00:01.0771200
        Button2 --------------------------
        00:00:01.0812499
        00:00:01.0813443
        效率差多少？在这里时间还不到1%，代码少写一个if字句
        看到有文章说这种方法在大量更新ui时会引发大量异常，导致性能下降
        我测试了一下，耗时和循环次数是很平稳的线性关系，而且也没有发现几个Exception相关性能计数器有问题，这说明这又是某老外朋友想当然的说法。

        2、CheckForIllegalCrossThreadCalls在.net1.x中默认是false，也就是不检查，.net2.0和3.x默认是true
        说明这是ms有意的引导，说不定以后不让你改了。这也是很多1.x用户在刚用2.0时不习惯跨线程更新ui的原因之一。

        3、死穴：安全性
        CheckForIllegalCrossThreadCalls容许子线呈随时更新ui，在同一个test函数体内，不能保证自身事务的一致性。给label1付了值
        一回头，就已经被别人改了，这和超市的踩踏事件的后果一样严重。
        当然你可以自己加锁，用信号量，这样还不如直接使用Invoke了，你只是又把别人做好的事情做了一遍。

        如果你觉的你的应用不会考虑在写入ui的同时来读取ui，而倾向使用CheckForIllegalCrossThreadCalls来追求效率的话，也是不恰当的做法。
        首先CheckForIllegalCrossThreadCalls并不能让效率发生本质的变化。
        其次需求永远是变化的，现在不考虑不等于以后不会碰到
        听从ms的引导。否则以后要在高版本的.net framework中移植代码的时候需要花费数倍的人工。

  using   System;