Multithreading 更新每个线程'；在没有CPU过载的情况下在TListView中设置计时器

德尔福使用：2007

各位好,

我有一个TListView，其

ViewStyle

设置为

vsReport

。当我点击一个按钮时，我会启动大约50个线程。每个线程都有一个

TListItem

组件。每个

t列表项

都有一个子项，它是一个计时器。从250开始一直到0。用户可以在TListView中看到每个计时器都在减少

我编写了以下代码：

procedure TThreadWorker.DeleteTickets;
begin
 ListItem.Delete;
end;

procedure TThreadWorker.UpdateTimer;
begin
 ListItem.SubItems[1] := IntToStr(Timer);
end;

procedure TThreadWorker.TimerCounter;
begin
 Timer := 300;
 repeat
  Sleep(1000);
  Dec(Timer);
  Synchronize(UpdateTimer);
 until (Timer = 0);
 Synchronize(DeleteTickets);
end;

而且。。。它起作用了！但问题是：所有这些同步似乎都不必要地使CPU过载。显然，当我启动更多线程（100、200或300）或使用较弱的计算机时，这是一个更大的问题。起初，我不确定是同步；但是如果我停用它们，CPU就不会过载了

坦率地说，这不是什么大问题。然而，我有一种感觉，递减计时器不应该导致任何类型的CPU过载：我的代码可能不正确。我试着少调用

UpdateTimer

，虽然它减轻了CPU过载，但最终并没有修复它。此外，我希望用户看到计时器每秒更新一次。计时器也需要尽可能精确

---

谢谢。

我认为线程对CPU来说比你想象的要贵。根据我的记忆，CPU有开销来交换缓存中的每个线程。由于CPU交换了50个不同的线程，我对它的过载并不感到惊讶

一种解决方案可能是扩展TTimer组件，然后动态创建其中的50个线程，而不是50个线程。TTimer使用windows api而不是线程。（下面的代码未经测试，但至少应提供idead）

如果所有线程都在同一时间启动，请尝试使用一个线程控制最多25个计时器。i、 对于50个计时器，您只有两个线程。然后计时器事件将循环通过其25个计数器并将其递减。您仍然需要为此使用同步

这个问题的答案可能很有趣：

---

这里是使用

TThread.Queue

和

TSimpleEvent

来计时计数器而不是

Sleep（）

的示例

类型
TThreadWorker=Class（TThread）
私有的
FTimer：整数；
FListItem:TListItem；
程序执行；推翻
程序更新程序；
手续票；
公众的
构造函数创建（aListItem:TListItem）；
结束；
构造函数TThreadWorker.Create（aListItem:TListItem）；
开始
继承创建（false）；
FListItem:=aListItem；
Self.FreeOnTerminate:=真；
结束；
程序TThreadWorker.Execute；
变量
anEvent:TSimpleEvent；
开始
anEvent:=TSimpleEvent.Create（nil，true，false，）；
尝试
FTimer:=300；
重复
anEvent.WaitFor（1000）；
队列（UpdateTimer）；
Dec（FTimer）；
直到（FTimer=0）；
自同步（删除票证）；// 我想你在这里是本末倒置了。让所有线程同步到主线程中，每个线程都有自己的计时器和消息队列，这将给系统带来沉重的负担。此外，通常情况下，您不希望运行消息循环给线程带来负担

在我看来，更好的方法是在主线程中放置一个计时器。当它滴答作响时，让它从需要报告的每个线程或任务中检索进度。您需要序列化对该进程的访问，但这并不昂贵。
1）不要使用50个线程，您可能没有50个内核。2） 使用消息传递，例如，使用队列而不是同步。@gabr 50（大多数时间处于休眠状态）线程不是问题，而是与主线程同步（每个线程几乎同时进行），并强制VCL重新绘制ListView。你的观点是错误的case@gabr+1表示TThread.queue帮助您解决这个人工问题听上去并不会有任何效果。真正的问题是什么？我想我们需要更多地了解真正的问题。在我的应用程序中，我有一个列表视图，可以报告许多不同任务的进度，通常每个线程一个。我用一个主线程计时器来处理这个问题，它会询问每个线程的进度。我认为这将比你的方法更具可扩展性。但我不知道你真正的问题是什么。在这个问题中，我没有看到一个
TTimer
，只有一个计时器——它似乎是一个简单的整数变量——我想到了它，但我听说TTimer可能不可靠，因为它们对Windows的优先级较低。这是真的吗？计时器事件是低优先级事件。我有使用200多个线程的应用程序，没有固有的问题。明智地使用它们当然总是明智的。只是要注意，我永远不会把逻辑部分（这里是TThread）和表示部分（这里是TListItem）混为一谈。这对OP来说比@LURD:o更重要）DeleteTicket也可以移动到事件处理程序（将在主线程的上下文中执行）
TMyTimer = class(TTimer)
begin
  public
    Timer: integer;
    ListItem: TListItem;
end;
...
procedure ButtonClick(Sender: TObject)
begin
  for i := 0 to 50 do
  begin
     ltimer = TMyTimer.Create;
     ltimer.Timer := 300;
     ltimer.ListItem := TListItem.Create;
     //initialize list item here
     ltimer.OnTimer := DecTimer;
  end;
end;

procedure DecTimer(Sender: TObject)
begin
  dec(TMytimer(Sender).Timer);
  TMyTimer(Sender).ListItem.SubItem[1] := StrToInt(TMytimer(Sender).Timer)
end;

Type
  TThreadWorker = Class(TThread)
  private
    FTimer : Integer;
    FListItem : TListItem;
    procedure Execute; override;
    procedure UpdateTimer;
    procedure DeleteTicket;
  public
    constructor Create( aListItem : TListItem);
  End;

constructor TThreadWorker.Create(aListItem : TListItem);
begin
  Inherited Create(false);
  FListItem := aListItem;
  Self.FreeOnTerminate := true;
end;

procedure TThreadWorker.Execute;
var
  anEvent : TSimpleEvent;
begin
  anEvent := TSimpleEvent.Create(nil,true,false,'');
  try
    FTimer := 300;
    repeat
      anEvent.WaitFor(1000);
      Queue(UpdateTimer);
      Dec(FTimer);
    until (FTimer = 0);
    Self.Synchronize( DeleteTicket); // <-- Do not Queue this !
  finally
    anEvent.Free;
  end;
end;

procedure TThreadWorker.UpdateTimer;
begin
  FListItem.SubItems[1] := IntToStr(FTimer);
end;

procedure TThreadWorker.DeleteTicket;
begin
  FListItem.Delete;
end;