Abbildung 30 zeigt einen allgemeineren Ansatz für die Kündigung. Dies kann verwendet werden, um einzelne Aufgaben, Regionen oder sogar ganze Fälle abzubrechen. Sie basiert auf der Erstellung einer alternativen “Bypass”-Aufgabe für jede Aufgabe in einem Prozess, der möglicherweise abgebrochen werden muss. Wenn ein Abbruch initiert wird, wird die Anfrage weiter verarbeitet, aber die “Bypass”-Aufgaben werden ausgeführt und nicht die normalen Aufgaben, so dass in der Tat keine weitere Arbeit an dem Fall tatsächlich erreicht wird. Dem Muster sind keine spezifischen Kontextbedingungen zugeordnet. Ein Angebot erhält die volle Unterstützung für dieses Muster, wenn es ein Konstrukt bereitstellt, das die Beschreibung für das Muster erfüllt. Wenn mit der Stornierung Nebenwirkungen verbunden sind (z. B. erzwungener Abschluss anderer Aufgaben, wobei die abgebrochene Aufgabe als abgeschlossen markiert wird), wird das Angebot als teilweise Unterstützung eingestuft. Diesem Muster ist eine wichtige Kontextbedingung zugeordnet: Die Löschung eines ausgeführten Falls muss als erfolgloser Abschluss der Anfrage angesehen werden. Dies bedeutet, dass, obwohl der Fall in geordneter Weise beendet wurde, vielleicht sogar mit Token, die ihren Endpunkt erreichen, dies in keiner Weise als ein erfolgreiches Ergebnis interpretiert werden sollte.
Wenn z. B. ein Protokoll von Ereignissen gespeichert wird, die während der Prozessausführung auftreten, sollte die Anfrage als unvollständig oder abgebrochen aufgezeichnet werden. Es ist auch ein gutes API-Muster, um Ihr CancellationToken als letzten Parameter zu behalten, den Ihre Methode akzeptiert. Dies passt sowieso gut zu optionalen Parametern, da sie nach allen erforderlichen Parametern angezeigt werden müssen. In Abbildung 29 wird ein alternatives Schema dargestellt, in dem jedem Staat eine Reihe von Abbruchübergängen zugeordnet ist (dargestellt durch C1, C2 … usw.). Wenn der Abbruch initiiert wird, werden diese Ãœbergänge für ein sehr kurzes Zeitintervall aktiviert (im Wesentlichen die Differenz zwischen Zeit t und t + Epsilon, wobei Epsilon ein Zeitintervall ist, das sich Null nähert), wodurch ein sofortiger Abbruch für einen bestimmten Zustand erfolgt, der die potenziellen Deadlocks vermeidet, die mit dem Ansatz in Abbildung 28 auftreten könnten. Unabhängig davon, ob Sie asynchronarbeiten oder nicht, ist das Akzeptieren eines CancellationToken als Parameter für Ihre Methode ein großartiges Muster, um ihrem Aufrufer zu ermöglichen, verlorenes Interesse am Ergebnis auszudrücken. Die Klassen System.Threading.Tasks.Task und System.Threading.Tasks.Task unterstützen den Abbruch durch die Verwendung von Abbruchtoken in .NET Framework. Weitere Informationen finden Sie unter Abbrechen in verwalteten Threads. In den Aufgabenklassen umfasst der Abbruch die Zusammenarbeit zwischen dem Benutzerdelegat, der einen abbruchfähigen Vorgang darstellt, und dem Code, der den Abbruch angefordert hat.