- Posted by Oliver on März 20, 2010
Wenn man denn unbedingt einen String als Lock-Objekt nutzen will und man sich davon überzeugt hat, nicht den Type eines gerade durch die Methode schwirrenden Objektes zu nutzen (das könnte ja jeder machen ;-)), dann sollte man auf jeden Fall an String.Intern(myLockString) denken!
Wo man kann, sollte man also weiterhin einen einfachen object-Lock nutzen:
1: private static readonly object _lock = new object();
Aber man darf dann nicht vergessen, dass alle Threads, die auf den Code im Lock zugreifen von einem einzigen Lock bedient werden. Wenn man die Threads aber in Gruppen aufteilen kann, die unabhängig voneinander arbeiten können, ist diese Beschränkung zu scharf. Ich suchte also einen Weg, einen eindeutigen Lock für jede dieser Gruppen (hier: TranslationGroup) zu generieren, der von allen Instanzen geteilt wird. Der Gruppenidentifikator heißt hier _pageNameKey.
Beispiel:
1: private const string _migrateLock = "9B90360AAF4342798A739DA2D85AF5AF"; // guid
2:
3: private string _pageNameKey = ...; // can be the same in multiple parallel threads
4:
5: public void Migrate(string oldGroupName, Dictionary<string, string> controlIdsOldToNew)
6: {
7: lock (string.Intern(_migrateLock + _pageNameKey))
8: {
9: // do something not here that should not be done in parallel
10: }
11: }
Ließe man in Zeile 7 das String.Intern(…) weg, würde bei jedem Aufruf der Methode ein neues String-Objekt generiert – was für dem Lock seine Existenzberechtigung raubt.
Gruß, Oliver
Wenn ihnen der Artikel gefallen hat oder er für sie hilfreich war, bitten "kicken" sie ihn.
