PowerShell: Warteschleifen ohne 100 % CPU-Last

Eine leere While-Schleife, die auf einen Thread wartet, legt einen kompletten CPU-Kern lahm. Ein einfaches Start-Sleep hilft – noch besser sind die eingebauten Warte-Mechanismen von PowerShell.

Wer in PowerShell mit einer while-Schleife auf eine Bedingung wartet – etwa auf das Ende eines Threads, Jobs oder Runspaces –, erzeugt schnell eine unnötig hohe CPU-Last. Läuft in der Schleife kaum Code, prüft sie die Bedingung millionenfach pro Sekunde und belegt dabei einen kompletten Prozessorkern.

Das Problem

while (-not $job.IsCompleted) {
    # nichts zu tun – trotzdem 100 % Last auf einem Kern
}

Die einfache Lösung: kurz schlafen

Schon eine winzige Pause senkt die Last auf nahezu null:

while (-not $job.IsCompleted) {
    Start-Sleep -Milliseconds 100
}

Der einzige Nachteil: Das Skript reagiert bis zu 100 Millisekunden später – in fast allen Fällen völlig unerheblich. Werte zwischen 50 und 500 Millisekunden sind ein guter Kompromiss zwischen Reaktionszeit und Last.

Noch besser: richtig warten statt abfragen

PowerShell und .NET bringen Mechanismen mit, die gar nicht abfragen, sondern benachrichtigt werden:

Hintergrundjobs:

$jobs = 1..5 | ForEach-Object { Start-Job -ScriptBlock { param($n) Start-Sleep 5; "Fertig $n" } -ArgumentList $_ }
$jobs | Wait-Job | Receive-Job

Runspaces mit asynchronem Aufruf:

$ps = [powershell]::Create().AddScript({ Start-Sleep 5; 'Ergebnis' })
$handle = $ps.BeginInvoke()
$handle.AsyncWaitHandle.WaitOne() | Out-Null   # blockiert ohne CPU-Last
$ps.EndInvoke($handle)
$ps.Dispose()

Prozesse:

$p = Start-Process notepad -PassThru
$p.WaitForExit()

PowerShell 7 – parallele Verarbeitung:

1..10 | ForEach-Object -Parallel { Start-Sleep 1; $_ } -ThrottleLimit 5

Faustregel

• Gibt es ein Wait-*-Cmdlet oder eine Wait…()-Methode, verwenden Sie diese.
• Müssen Sie selbst abfragen, bauen Sie immer ein Start-Sleep ein.
• Setzen Sie bei Warteschleifen ein Timeout, damit ein hängender Job nicht das ganze Skript blockiert.