★★★关于线程同步：
Synchronize()是在一个隐蔽的窗口里运行，如果在这里你的任务很繁忙，你的主窗口 会阻塞掉；Synchronize()只是将该线程的代码放到主线程中运行，并非线程同步。
临界区是一个进程里的所有线程同步的最好办法，他不是系统级的，只是进程级的，也就是说他可能利用进程内的一些标志来保证该进程内的线程同步，据Richter说是一个记数循环；临界区只能在同一进程内使用；临界区只能无限期等待，不过2k增加了TryEnterCriticalSection函数实现0时间等待。
互斥则是保证多进程间的线程同步，他是利用系统内核对象来保证同步的。由于系统内核对象可以是有名字的，因此多个进程间可以利用这个有名字的内核对象 保证系统资源的线程安全性。互斥量是Win32 内核对象，由操作系统负责管理；互斥量可以使用WaitForSingleObject实现无限等待，0时间等待和任意时间等待。
1. 临界区
临界区是一种最直接的线程同步方式。所谓临界区，就是一次只能由一个线程来执行的一段代码。如果把初始化数组的代码放在临界区内，另一个线程在第一个线程处理完之前是不会被执行的。在使用临界区之前，必须使用InitializeCriticalSection()过程来初始化它。 在第一个线程调用了EnterCriticalSection()之后，所有别的线程就不能再进入代码块。下一个线程要等第一个线程调用LeaveCriticalSection()后才能被唤醒。
2. 互斥
互斥非常类似于临界区，除了两个关键的区别：首先，互斥可用于跨进程的线程同步。其次，互斥能被赋予一个字符串名字，并且通过引用此名字创建现有互斥对象的附加句柄。
提示：临界区与事件对象(比如互斥对象)的最大的区别是在性能上。临界区在没有线程冲突时，要用10 ~ 15个时间片，而事件对象由于涉及到系统内核要用400~600个时间片。
当一个互斥对象不再被一个线程所拥有,它就处于发信号状态。此时首先调用WaitForSingleObject()函数的线程就成为该互斥对象的拥有者，此互斥对象设为不发信号状态。当线程调用ReleaseMutex()函数并传递一个互斥对象
的句柄作为参数时，这种拥有关系就被解除，互斥对象重新进入发信号状态。
可以调用函数CreateMutex()来创建一个互斥量。
当使用完互斥对象时，应当调用CloseHandle()来关闭它。
3. 信号量
另一种使线程同步的技术是使用信号量对象。它是在互斥的基础上建立的，但信号量增加了资源计数的功能，预定数目的线程允许同时进入要同步的代码。可以用CreateSemaphore()来创建一个信号量对象， 因为只允许一个线程进入要同步的代码，所以信号量的最大计数值(lMaximumCount) 要设为1。ReleaseSemaphore()函数将使信号量对象的计数加1； 记住，最后一定要调用CloseHandle()函数来释放由CreateSemaphore()创建的信号量对象的句柄。
★★★WaitForSingleObject函数的返值：
WAIT_ABANDONED指定的对象是互斥对象，并且拥有这个互斥对象的线程在没有释放此对象之前就已终止。此时就称互斥对象被抛弃。这种情况下，这个互斥对象归当前线程所有，并把它设为非发信号状态；
WAIT_OBJECT_0 指定的对象处于发信号状态；
WAIT_TIMEOUT等待的时间已过，对象仍然是非发信号状态；
问题: 关于线程的简单问题:线程与界面
来自: painboy, 时间: 2005-03-01 12:58:09, ID: 3001075
当有若干个同类线程对界面的同一个VCL控件进行操作进，必须用Synchronize来同步。
就你的情况来说，设有10个FiveQuery线程进行查询，查询所耗时间约8秒，线程更新界面所需时间大约1秒，这样当你一运行10线程时，前8秒时间界面是可以进行其他操作的，但约8秒后，连续进行10X1即10秒的界面更新，这就会出现10秒左右的“忙沙漏”。
所以，要避免这情况，一是减少并发运行的线程数；二是缩短SynchronizeSource执行时间。优化你的同步更新过程，同时把尽可能的代码写在Execute里。
来自: ppqingyu, 时间: 2005-03-01 17:42:45, ID: 3001730
呵呵...那像我上面的那些代码还有得救吗?同步的过程全是关于界面更新的呀.
来自: panbq, 时间: 2005-03-06 0:46:20, ID: 3004732
我碰到的问题跟楼主一样,不过把同步部分的代码写到一个线程的EXECUTE里,在更新的时候,创建此更新线程,界面无响应问题就解决了.
来自: ppqingyu, 时间: 2005-03-06 10:07:03, ID: 3004839
不是说界面更新在线程是不是安全的吗?这样不会有问题?
来自: panbq, 时间: 2005-03-09 19:28:38, ID: 3009426
把界面更新的部分在线程里单独写一个过程，如：
procedure Tprocess_data.show_me;
begin
form1.statusbar1.simpletext:=mtt(mtt为线程里的一个局部变量）
end;
在线程的执行过程里这样写：
...处理数据
mtt:=要显示的信息
Synchronize(show_me);
这样同步过程将非常短，同步只是在主界面显示信息而已，而不是把整个处理过程都写进同步过程中去。。。
问题: 是否可以不用Synchronize?
来自: jackchin, 时间: 2004-08-26 11:59:00, ID: 2780104
procedure TForm1.ChangeCaption(NewCaption: String);
begin
Label1.Caption := NewCaption
end;
多个线程调用以上的代码, 是否可以不用Synchronize?
即, 不用Synchronize, 访问、更新TLabel的属性是否安全?
来自: 迷糊, 时间: 2004-08-26 12:06:13, ID: 2780123
多线程更新TLabel的属性肯定不安全，所以要同步，但是同步可以不用Synchronize
比如在子线程中发消息通知主线程更新label
来自: maoyihua, 时间: 2004-08-26 12:23:51, ID: 2780146
同意楼上的观点，只要是对于界面有关的操作，都需要使用Synchronize来同步；不过使用消息机制也是一个不错的办法。
来自: jackchin, 时间: 2004-08-26 14:40:55, ID: 2780427
我有一个多线程程序, 偶然会发生不能处理的意外, 估计是线程出问题了
线程除了上述更新界面的操作外,还有 Getmem, FreeMem, PaintBox.Canvas.Paint等
另外, 还有数据库操作(用BDE), 我用以下临界段保护的方法
DBCritical.Enter;
// here is database access code using TQuery,TTable...
DBCritical.Leave;
这些都没有用Synchronize, 不知道是不是有问题
来自: 迷糊, 时间: 2004-08-26 16:42:23, ID: 2780709
这么频繁的界面操作，你还是考虑一下是不是一定要用多线程
你的临界段保护在主线程中也写了吗？如果没有的话没办法保护。
问题: 怎么用多线程操作listView。
来自: 留香客, 时间: 2004-10-19 20:28:00, ID: 2855263
我有一个数据库，要把数据全部读入到ListView中。然后进行数据的计算。
ListView中有两个部分：名称和进度。
我在线程中，不停查找与当前名称相符的TlistItem，更新进度的值，如果进度为100％，则删除。
但是即使我用了DoubleBuffer也闪的很厉害，有时候就是一片白色的，还老出错：out of index。我也用BeginUpdate和EndUpdate，就是一片白色。
大侠帮我看看吧。
来自: 陷队之士, 时间: 2004-10-19 20:59:55, ID: 2855320
我个人认为，之所以能出现你所说的闪烁现象，根本原因不在于你是一个线程，还是几个线程，而在于你处理数据的“场所”。就是说，你的数据如果放在TStringList中处理，处理完后再在ListView中显示出来，可能就会好很多。TStringList与ListView的区别在于，前者只是在背后保存数据、处理数据，而后者不仅要保存数据，更重要的是要显示出来，这就大大限制了速度。
我们在用某些多文件搜索功能时，会发现，在搜索时，如果你让显示搜索结果的窗口缩得很小，或根本就关闭，这时，它会搜索得非常快，反之，将搜索结果窗口弄得很大，它一边搜索，一边添加显示结果，速度就慢很多。
我想，这和你的情况是一个道理。
来自: 刘麻子, 时间: 2004-10-19 21:23:45, ID: 2855359
能不能用一个线程负责和界面通讯，其他的线程计算，并把进度发给界面通讯线程.
－－－－－－－－－－－－－－－－－－－－－－－－－－－－
对拉，这个思路很好，多线程就是这样用的。
计算线程都Post消息给通讯线程的话，会不会通讯线程忙不过来而漏掉一些消息呢？
－－－－－－－－－－－－－－－－－－－－－－－－－－－－
漏掉倒不大会，但是可能不及时，界面线程可适当调用Application.ProcessMessages;
问题: 請教富翁們在多線程中,各個線程能同時去訪問主界面的控件嗎
来自: gemmy, 时间: 2003-02-18 15:35:00, ID: 1629597
比如,每個線程都要訪問主界面的stringGrid控件但不對它進行編寫
来自: vine, 时间: 2003-02-18 15:45:00, ID: 1629629
用synchronize（）方法来
这个方法会做一些工作，把传入的方法交由主线程来执行
来自: barton, 时间: 2003-02-26 16:02:00, ID: 1645470
有关线程，我谈点看法。
对于大多数非可视控件，线程可以并行安全操作。读写Canvas的VCL通过锁定Canvas来实现
多线程的访问，但是事实上一个线程在访问的时候，另一个线程处于等待状态。实现这种
访问的控制并不需要通过Synchrinize来实现，而是Canvas自己带一个同步对象，实现重入
限制。Synchrinize只能保证同类型的多个实例不会同时执行某个过程，并不能实现多个不
同类线程间的同步控制。
数据库访问应该尽可能避免在线程中访问。Delphi中的TDataset并不是线程安全的，它对
线程的限制比VCL还严格。所以大多数数据库引擎中自己带有同步机制，保证多线程间的同
步。不过，大家知道，应用程序消息循环总是单线程的，基于这个原因，我总是直接通过
消息来同步，又方便又安全。如果是要求即时应答，线程通过SendMessage向父窗口发送消
息，否则通过PostMessage向父窗口发送消息，这样，线程通过PeekMessage循环获得父窗
口返回的消息，必要时还可以在线程中加入事件机制实现线程安全。
来自: shenjian, 时间: 2003-07-26 16:10:00, ID: 2061692
非常赞同barton的看法，对界面控件和非界面控件的交互部分最好使用消息驱动的方式，使用多线程访问界面你不是绝对的高手，你是难以驾驭的。而且通常你那样做反而容易破坏程序良好的结构，导致界面部分和下面捆的很紧。
问题: 使用Synchronize()和使用临界区,互斥对象有何区别?性能差异这么大.为何还要存在互斥同步? ( 积分: 100 )
来自: 淡淡的笑, 时间: 2002-08-13 10:51:00, ID: 1260767
不是指在使用方法上,而是性能及其它细节方面.(书上没有讲到这个,只讲到临界区与事件对象[互斥
对象]的最大区别是在性能上)
既然临界区比互斥对象的性能要高40倍左右,为何还要存在互斥同步?哪种情况下(必须)使用互斥同步比较好?
来自: 张无忌, 时间: 2002-08-13 11:49:00, ID: 1260893
Synchronize()是在一个隐蔽的窗口里运行，如果在这里你的任务很繁忙，你的主窗口
会阻塞掉，我做过测试
临界区是一个进程里的所有线程同步的最好办法，他不是系统级的，只是进程级的，
也就是说他可能利用进程内的一些标志来保证该进程内的线程同步，据Richter说
是一个记数循环。
互斥则是保证多进程间的线程同步，他是利用系统内核对象来保证同步的。
由于系统内核对象可以是有名字的，因此多个进程间可以利用这个有名字的内核对象
保证系统资源的线程安全性
问题: 一种程序死亡的方式：SendMessage的后果
主线程和子线程需要交换数据：
主线程这样运行：
1。进入临界区
2。访问全局共享数据
3。离开临界区
子线程如下运行：
1。进入临界区
2。访问全局共享资源
3。调用SendMessage发消息给主线程
4。离开临界区
5。Sleep(100)
6。进行循环，直到主线程退出
这么简单的一个多线程的程序，
竟然经常的死掉，怀疑是SendMessage造成的
在线程中调用那个同步的方法也会出现死锁
因为他也间接调用了SendMessage的方法
所以，这样的多线程模式，慎用SendMessage
来自：daxian, 时间：2004-3-17 23:35:06, ID：2508161
你这么做是找死，SendMessage 的接收消息的窗体的 窗体回调函数 是在主线程内
而 SendMessage 调用后要等待 消息处理的结束后才返回， 如果这时侯主线程等待进入临街区那么，这就是典型的死锁现象。
同步方法虽然也间接调用了 SendMessage 但是Delphi作了巧妙的处理而不会进入死锁，你调用会死锁那是你程序上有错误。
这里你可以用 PostMessage 它不等待消息处理的结束，直接返回
来自：vonrao, 时间：2004-3-17 23:38:57, ID：2508165
如果使用Sendmessage，必须等到接受线程线程跳出才返回，这样有可能造成死锁，我有感与你的观点。一般在通知时我使
用PostMessage或创建一个事件机制，来协调多个线程的同步问题。
来自：lich, 时间：2004-3-18 20:47:00, ID：2510034
设计多线程时，有一个原则，一定要记住，
就是，锁定的时间尽可能的短，锁定期间做尽可能少的操作，再者，慎用SendMessage
来自：daxian, 时间：2004-3-18 22:10:58, ID：2510195
我现在没有以前版本的Delphi，在那些版本的Delphi用了CM_EXECPROC消息已进行同步然后再主线程内在作相应处理，如下
function TThread.WaitFor: LongWord;
var
Msg: TMsg;
H: THandle;
begin
H := FHandle;
if GetCurrentThreadID = MainThreadID then
while MsgWaitForMultipleObjects(1, H, False, INFINITE,
QS_SENDMESSAGE) = WAIT_OBJECT_0 + 1 do PeekMessage(Msg, 0, 0, 0, PM_NOREMOVE)
else WaitForSingleObject(H, INFINITE);
GetExitCodeThread(H, Result);
end;
在新版本的Delphi内则使用了事件（Event）和临界区（CriticalSection）的配合来进行同步
来自：lich, 时间：2004-3-19 19:12:42, ID：2511613
我又看了一下Classes.pas中TThread类的实现，同时又测试了一下，使用同步方法Synchronize也可能造成死锁
死锁条件如下：主线程进入等待，等待子线程完成本轮操作，
子线程此时调用Synchronize方法，而子线程必须等待Synchronize返回后才能继续执行，此时造成死锁
来自：lich, 时间：2004-3-20 14:03:08, ID：2512394
>>像这样的操作，本身是一种错误，子线程的存在就是为了让主线程不进行等待。
世事无绝对,典型以生产者消费者模式为例，主界面为生产者,人工录入,或由主线程接收数据
交给子线程处理,但是限制了缓冲队列的长度
这样,当缓冲区不够时,主线程必然需要等待,
缓冲区空时,子线程等待,子线程有可能通过同步方法,
将反馈消息显示到主线程的人机界面.,就有可能会出现我所说的
那种死锁条件了
如果不限制缓冲的大小,也不会有这种同步问题了
但是,线程同步也就没有必要讨论了