Скорость работы с lock

@Martovskij · Регистрация: 30.01.2011

Студворк — интернет-сервис помощи студентам

Здраствуйте уважаемые специалисты по .NET.
Разрабатываю сервер на C# и озадачился вот каким вопросом:

допустим имею List<Socket>, в листе находится 20 объектов, от первого объекта (сокета) поступает сообщение, которое я должен либо

а) дублировать всем объектам в листе

либо

б) дублировать одному конкретному объекту

Все работает правильно в рассужденияъ, если в данный момент с List<Socket> работает один поток.
Но если к List<Socket> вдруг обратятся одновременно 20 потоков (от всех пришло сообщение), которые не только проходят по листу и отправляют месседж, а еще и на основании содержимого месседжа могут закрыть сокет и удалить его из листа, то в таком случае терзают смутные сомнения, каким образом разрулить атомарный доступ и не потерять производительность.

C#
1
2
3
4
5
6
7
8
9
10
11
12
String targetIp,msg;
lock(socketListMutex)
{
    for(int i =0; i < listSocket.Count; i++)
    {
        if(listSocket.elementAt(i).targetIp==targetIp)
        {
            listSocket.sendTo(msg);
            break;
        }
    }
}

И еще один вопрос,
все-таки volatile list или non-volatile list?

@Grishaco · 29.01.2014, 11:04

Сообщение от Martovskij

каким образом разрулить атомарный доступ и не потерять производительность.

Лучше для каждого сокета реализовать собственную очередь сообщений. Это позволить ставить lock только на добавление сообщения.

lock не влияет на производительность (во всяком случае ощутимо).

@Martovskij · 29.01.2014, 12:05 **[ТС]**

Хм... то есть ничего, что в

C#
1
2
3
4
lock(mutex)
{
   io operation
}

????

Дак всё-таки volatile list<T> или нет?

@Grishaco · 29.01.2014, 12:07

Сообщение от Martovskij

Дак всё-таки volatile list<T> или нет?

Все зависит от того, как вы его создаете, если до поднятия сервера, тогда не надо, если после, то добавьте.

@Anklav · 29.01.2014, 13:22

Этим модификатором помечается переменная которая может быть изменена из разных потоков, без синхронизирующих конструкций, допускающих изменять ее только 1 потоку.

В данном случае вы хотите пометить им ссылочный тип, а значит, что значение переменной можно менять из разных потоков. Но значение переменной для ссылочного типа это всегда ссылка. А вы же не меняете в каждом потоке ссылку, вы меняете объект по ссылке, по этому этот модификатор, данном случае вообще не имеет никакой ценности.

@Wolfdp · 29.01.2014, 13:25

Сообщение от Grishaco

Лучше для каждого сокета реализовать собственную очередь сообщений. Это позволить ставить lock только на добавление сообщения.

может случится вот что:

- один из 20 отваливается.
- в списке удаляется отвалившийся сокет, причем он был в начале. Как следствие -- список сдвинулся влево.
- в это время всем рассылалось сообщение и цикл стоял в середине. Как следствие -- пропустится один сокет.

По идеи listSocket.sendTo(msg); должно асинхронно закидывать в поток текущему сокету сообщение. То есть вызвали метод и "моментально" идем дальше, а он себе в другом потоке отсылает.

@Grishaco · 29.01.2014, 13:34

Сообщение от Wolfdp

может случится вот что:
- один из 20 отваливается.
- в списке удаляется отвалившийся сокет, причем он был в начале. Как следствие -- список сдвинулся влево.
- в это время всем рассылалось сообщение и цикл стоял в середине. Как следствие -- пропустится один сокет.

Я говорю не про это, не знаю как там с методом sendTo, но догадываюсь, что если я буду посылать большой объем данных за короткий промежуток времени, то он отвалится (или у него есть внутренний буфер?).

У каждого есть своя очередь, не важно где он в верху или в низу, мы просто ему говорим что есть сообщение, а он уже сам решает когда его послать.

Описанная вами проблема отсутствует.

@Martovskij · 29.01.2014, 13:39 **[ТС]**

Сообщение от Wolfdp

может случится вот что:
....
Как следствие -- пропустится один сокет.

Да, именно в этом и проблема

Поэтому надо лочить проход по листу и этим же мьютексом лочить удаление из очереди, но что будет если поток каждого клиента будет лочить лист... боюсь получить тормоза при интенсивном обмене..

Добавлено через 2 минуты

Сообщение от Grishaco

Описанная вами проблема отсутствует.

Вы точно в этом уверены?

Когда делал точно такое же на Java без синхронизации у меня были "трудноуловимые баги", когда месседж
приходил не всем клиентам.

Добавлено через 1 минуту

Сообщение от Anklav

Volatile в данном случае вообще не имеет никакой ценности.

Огроменное спасибо, я затупил(((

@Grishaco · 29.01.2014, 13:40

Сообщение от Martovskij

Вы точно в этом уверены?

Все зависит от реализации того, что вы пишите. Я не говорил про управление коллекцией, я говорил про сообщения. То что вам придется лочить коллекцию для добавления, удаления, это и так ясно.

@Martovskij · 29.01.2014, 13:43 **[ТС]**

Сообщение от Grishaco

То что вам придется лочить коллекцию для добавления, удаления, это и так ясно.

+ обход.

не ясно насколько будет это тормозить конечное приложение при кол-ве клиентов 10-50
при наихудшем раскладе.

@Grishaco · 29.01.2014, 13:45

Сообщение от Martovskij

не ясно будет ли это тормозить конечное приложение при кол-ве клиентов 10-50

Опять же все зависит от реализации. Ответьте на один вопрос, что будет если я напишу следующий код, как поведет себя приложение.

C#
1
2
3
4
5
6
7
8
9
10
11
while(true)
{
for(int i =0; i < listSocket.Count; i++)
    {
        if(listSocket.elementAt(i).targetIp==targetIp)
        {
            listSocket.sendTo(msg);
            break;
        }
    }
}

@Martovskij · 29.01.2014, 13:46 **[ТС]**

Пока что нет возможности сделать профайлинг.. вот и интересуюсь, заранее так сказать....

Добавлено через 45 секунд
Код исполняется одним потоком?

@Grishaco · 29.01.2014, 13:47

Да.

@Martovskij · 29.01.2014, 13:52 **[ТС]**

По логике поток должен каждый раз обходить List на выявление нужного элемента.
Но возможно (говорю, как человек представляющий процессы под капотом CLR слабо и в теории),
что JIT оптимизирует обход листа закэшировав одного клиента.

@Grishaco · 29.01.2014, 13:57

Сообщение от Martovskij

По логике поток должен каждый раз обходить List на выявление нужного элемента.
Но возможно (говорю, как человек представляющий процессы под капотом CLR слабо и в теории),
что JIT оптимизирует обход листа закэшировав одного клиента.

Я не про это. Представьте у вас есть один клиент, и вы ему шлете данные непрерывно, будет ли задержка в отправке, т.к. клиент еще не обработал предыдущее сообщение? Или будет потеря сообщения?

Если первый вариант, то вы столкнетесь с ситуацией, когда нужно отправить сообщение всем клиентам, но какой то из них задержит очередь, просто зависнет. Еще может быть проблема с очередностью сообщений.

Если будет потеря сообщения, тогда это еще большая проблема.

@Martovskij · 29.01.2014, 14:04 **[ТС]**

Хех

Зависит от реализации.

При синхронной записи поток запишет в буфер сокета и пойдет дальше, если сокет еще не прожевал данные от предыдущей записи, поток дождется пока сокет закончит.
При асинхронной, вызовется (асинхронно) процедура записи в сокет, а поток обхода пойдет далее....

таки да, если интенсивно грузить асинхронной записью - может случится лажа, если синхронно грузить, могут случится тормоза или переполнение буфера (потеря месседжа)
на приемной стороне.

Вообщем идею я понял, нужна дополнительная прослойка между сокетом с его бУферами и основным потоком. Этакий AsyncWriter, контролирующий правильную запись в сокет
со своим Concurrent.List<T>.

@Grishaco · 29.01.2014, 14:06

Сообщение от Martovskij

Вообщем идею я понял, нужна дополнительная прослойка между сокетом с его бУферами и основным потоком. Этакий AsyncWriter, контролирующий правильную запись в сокет

Я про это и писал, делайте обертку над сокетом, для него делает очередь сообщений, которая не зависит от общего механизма, другой поток и т.д. И обрабатываете добавление удаление сокетов отдельно. И никакие тормоза не будут страшны.

@Martovskij · 29.01.2014, 14:07 **[ТС]**

спасибо, вопрос исчерпан

Новые блоги и статьи Все статьи Все блоги /
Кто-нибудь знает, где можно бесплатно получить настольный компьютер или ноутбук? США. Programma_Boinc 26.12.2025 Кто-нибудь знает, где можно бесплатно получить настольный компьютер или ноутбук? США. Нашел на реддите интересную статью под названием «Кто-нибудь знает, где получить бесплатный компьютер или. . .	Thinkpad X220 Tablet — это лучший бюджетный ноутбук для учёбы, точка. Programma_Boinc 23.12.2025 Рецензия / Мнение/ Перевод Нашел на реддите интересную статью под названием The Thinkpad X220 Tablet is the best budget school laptop period . Ниже её машинный перевод. Thinkpad X220 Tablet —. . .	PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Как объединить две одинаковые БД Access с разными данными VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro
Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .

@Anklav 447 / 305 / 47 Регистрация: 23.01.2013 Сообщений: 661
	29.01.2014, 13:22
	Этим модификатором помечается переменная которая может быть изменена из разных потоков, без синхронизирующих конструкций, допускающих изменять ее только 1 потоку. В данном случае вы хотите пометить им ссылочный тип, а значит, что значение переменной можно менять из разных потоков. Но значение переменной для ссылочного типа это всегда ссылка. А вы же не меняете в каждом потоке ссылку, вы меняете объект по ссылке, по этому этот модификатор, данном случае вообще не имеет никакой ценности. 1

@Martovskij 99 / 39 / 12 Регистрация: 30.01.2011 Сообщений: 129
	29.01.2014, 13:46 [ТС]
	Пока что нет возможности сделать профайлинг.. вот и интересуюсь, заранее так сказать.... Добавлено через 45 секунд Код исполняется одним потоком? 0

@Grishaco 438 / 362 / 100 Регистрация: 29.06.2010 Сообщений: 981 Записей в блоге: 1
	29.01.2014, 13:47
	Да. 0

@Martovskij 99 / 39 / 12 Регистрация: 30.01.2011 Сообщений: 129
	29.01.2014, 13:52 [ТС]
	По логике поток должен каждый раз обходить List на выявление нужного элемента. Но возможно (говорю, как человек представляющий процессы под капотом CLR слабо и в теории), что JIT оптимизирует обход листа закэшировав одного клиента. 0

@Martovskij 99 / 39 / 12 Регистрация: 30.01.2011 Сообщений: 129
	29.01.2014, 14:04 [ТС]
	Хех Зависит от реализации. При синхронной записи поток запишет в буфер сокета и пойдет дальше, если сокет еще не прожевал данные от предыдущей записи, поток дождется пока сокет закончит. При асинхронной, вызовется (асинхронно) процедура записи в сокет, а поток обхода пойдет далее.... таки да, если интенсивно грузить асинхронной записью - может случится лажа, если синхронно грузить, могут случится тормоза или переполнение буфера (потеря месседжа) на приемной стороне. Вообщем идею я понял, нужна дополнительная прослойка между сокетом с его бУферами и основным потоком. Этакий AsyncWriter, контролирующий правильную запись в сокет со своим Concurrent.List<T>. 0

@Martovskij 99 / 39 / 12 Регистрация: 30.01.2011 Сообщений: 129
	29.01.2014, 14:07 [ТС]
	спасибо, вопрос исчерпан 0

Скорость работы с lock

Решение