Leistungseinbußen bei der Verwendung von lock in try

9

Ich habe einen MockHttpListener Callback im Unit-Test verwendet. Ich habe wie folgt eine Sperre hinzugefügt:

%Vor%

Ich habe ein Problem festgestellt, bei dem der Test aufgrund der "zu langen" Kriterien fehlgeschlagen ist (dieses Problem trat vor dem Hinzufügen der Sperre im Test nicht auf.)

Ich habe viele Dinge ausprobiert, um das Problem zu identifizieren, und das einzige Problem, das das Problem behoben hat, war, die Sperre aus dem try-Block zu entfernen:

%Vor%

Die Verhaltensänderung ist konsistent hinsichtlich der Tatsache, dass die Sperrposition relativ zum try-Block die Dauer des Tests beeinflusst hat.

Hat jemand eine Idee, was den Grund angeht?

    
shlomi 30.06.2016, 07:05
quelle

1 Antwort

0

Das hört sich an, als wäre es ein Deadlock - ruft der Code "do somethat short" irgendeinen Code auf, der selbst eine Sperre übernimmt?

Der folgende Code funktioniert wie erwartet - nicht zu sagen, das ist eine gute Idee, aber es endet ohne Probleme.

%Vor%     
Adam Brown 15.12.2017 11:28
quelle

Tags und Links