http://msdn.microsoft.com/zh-cn/library/ms173179.aspx
参考

我昨天现学的多线程，这个效果既要等待，又不能阻塞主线程GUI界面响应，

最后用了两条线程解决问题，先开一条线程A，然后从线程A再开线程B。

线程B负债真正的费时工作，工作开始时加一个线程锁lock住，

线程A在开启工作线程B后，等待500毫秒（保证线程B的lock已经锁住了），

然后也进入lock代码，这样就造成了线程A的等待效果，待线程B完成后，线程A继续

这样两条线程互相配合，效果还不错

thread.join啦，waithandle.wait啦等等。

你应该在你的语句执行完毕之后，才创建子线程。

如果你提前创建什么子线程，干什么使？自己找事，你就会用一堆更多余东西来“圆那个慌”。其实本着一个简单的原则，你就没有多余的什么烦恼。

最垃圾的，就是有些从java入门书籍上学了点“生产者消费者模式”的人说的什么“两个队列、两个线程”的做法。这往往是低效和低水平服务程序的根源。

如果生产者通知系统它生产了一个东西，这个时候你的系统直接从线程池中分配一个子线程来处理这个东西，就行了。然后处理完这个东西，这个处理方法也就结束了。根本不存在什么“两个线程、两个队列”那回事。

你可以看到，如果系统资源足够，可能一瞬间同时有20个线程在那里消费产品，可能另一个瞬间只有2个线程。这是自动化地。根本不是什么“一个消费线程、顺序处理消费队列”。

其原则其实非常简单，就是线程中根本不需要什么while循环语句、阻塞语句之类的。如果一个线程没有事情可做，它就应该结束。搞懂这个原则，你才能够写出高效率的多线程处理程序。

通常我们在线程中需要“阻塞”，是因为没有时间仔细设计多线程下的程序控制流程，而简单地一直原本顺序处理的流程。当你简单地移植顺序处理的流程，而又想追求“多线程”的时髦和（貌似）美好的名词儿，你就会产生“阻塞式”的想法。如果这个阻塞过头了，甚至把什么“生产者消费者模式”都搬出来了，你就产生了效率特别低下、队列同步式的所谓想法了。

其实多线程编程，需要从流程上进行重构。仅仅在回调、事件通知的时候才启动子线程。

如果你经常纠结于“同步”问题，你达不到多线程编程的真正目的。大多数时候还不如不去玩儿什么多线程。

加上lock(object)

也不能一棍子打死吧
比如Unity3d里,要控制场景里的物体,代码必须放到主线程里,没有invork方法
那么我必须保证负责通信的线程已经取到了数据并比较出差异,需要更新,才执行主线程里的方法
总不能动态创建个主线程出来吧
这个具体问题还是要具体分析

有些线程无法关闭,动态生成
那么可以放到循环或timer里(Unity3d里是update),用变量控制方法执行或不执行
其他线程处理好之后修改这个变量就行了

有些不一定要用线程，既然有先后顺序，何不用回调函数或者事件方式呢

引用 4 楼 sp1234 的回复:

你应该在你的语句执行完毕之后，才创建子线程。

如果你提前创建什么子线程，干什么使？自己找事，你就会用一堆更多余东西来“圆那个慌”。其实本着一个简单的原则，你就没有多余的什么烦恼。

好久前的问题了，现在看来确实是你说的那样。