Home/ Questions/Q 8375371
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-09T15:09:30+00:00

I wrote a Win32 application (in Delphi-7 which is 32-bit using TThread class) to

  • 0

I wrote a Win32 application (in Delphi-7 which is 32-bit using TThread class) to create 100 threads. Each thread when resumed will continuously (in a loop) increment a 64 bit counter associated with the thread object (so no locking or sharing of data).

If you let the system run for 10 to 15 seconds and stop after that, you should see roughly the same counts in each of the threads. But what I observed was that 81 threads ran under 400 million loops and the remaining ones looped more than 950 million times. Slowest thread got only 230 million compared to the fastest 2111 million.

According to MSDN, the preemptive multitasking is at the thread-level (not process level), so each of my thread should have gotten its time-slice in a round-robin fashion. What am I missing here and why is this discrepancy?

Edit1: Machine configuration: Intel i7 Quad Core 3.4GHz with hyper-threading turned on (8 active threads at a time). Running Windows-7 64 bit professional (and the test application is 32 bit)

Edit2 (thread code): The test application is built with optimization turned on and without any debug info. Run the test application outside of IDE.

type

  TMyThread = class(TThread)
  protected
    FCount: Int64;
  public
    constructor Create;
    procedure Execute; override;
    property Count: Int64 read FCount;
  end;


{ TMyThread }

constructor TMyThread.Create;
begin
  inherited Create(True);
  FCount := 0;
end;  

procedure TMyThread.Execute;
begin
  inherited;
  while not Terminated do
  begin
    Inc(FCount);
  end;
end;
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Round-robin scheduling is an obvious strategy for a kernel. That’s however not the way that the Windows scheduler works. It used to, back in the Windows 9x days, a scheduler which was very capable of giving various VMs equal time. But not in the NT branch, started by Dave Cutler’s group, scheduling is purely based on priority.

    Whatever thread has the highest priority gets the cpu. There’s another chunk of code in Windows that tinkers with a thread’s priority, modifying it from the default priority it gets when the thread got created. That code is aware of stuff like a thread owning a window that’s in the foreground. Or a thread that’s waiting for a synchronization object that got signaled. Or the more bizarre scheduling problems that tries to solve a priority inversion problem. Randomly giving a thread a chance to run even though it wasn’t its turn.

    Focus on writing sane code first. Starting a hundred threads isn’t a very sane thing to do. You are trying to consume resources that the machine doesn’t actually have available, nobody has a machine with a hundred cores. Yet. Powers of two, get a machine with 128 cores first.

    • 0