Полагаю, вы читаете намного больше, чем пишете? Если это так, ReaderWriterLockSlim
может быть более подходящим для уменьшения блокировки (возьмите чтение, когда вы просто хотите проверить ключ, и напишите, чтобы манипулировать данными).
Я имею в виду, что сначала вы можете дважды проверить блокировку с чтением, а затем, если она не удастся, взять блокировку записи, снова проверить и добавить, если необходимо.
Также - lock(this)
обычно осуждается; предпочтительнее иметь отдельный объект блокировки.
Обратите внимание, что для вступления в силу все доступ должен учитывать блокировку; Есть места, где UsersOnline
заблокирован, и некоторые места, где он доступен без блокировки, например; эти вторые случаи могут взорваться в липком беспорядке.
Например:
if (!UsersOnline.ContainsKey(u.GetUserId()))
{
if (User.ValidateUser(u.GetUserId(), u.GetPassword(), con))
{
/*CHANGE 1.2.10 00:14*/
lock (UsersOnline)
{
UsersOnline.Add(u.GetUserId(), e.ClientSocket);
В приведенном выше примере, если возможно, что два потока смотрят на UsersOnline
, то вы уже потерпели неудачу, пытаясь ContainsKey
без блокировки. Если другой поток изменяет состояние при этом .... boom .