Особенности использования стандартных lock'ов для многопотока

[Yuriy Zymlex]

Так и пишут в библиотеке, что SyncObjects.ListSyncer является устаревшим, используйте FileSyncObjects.ListSyncer.

Вы можете и дальше использовать "устаревшие" поля, удалять их не будут.

Новый FileSyncObjects.ListSyncer тоже блокирует все шаблоны?

Как помню, да + обладает дополнительной логикой для установки приоритетов.
Уточню по примерам FileSyncObjects у разработчиков.

 

[Yuriy Zymlex]

Может админы или модераторы прокомментируют?

Данный способ чуть менее производительный, но даёт чуть больше контроля:

using (FileSyncObjects.ListSyncer.Lock())
{
    // код со списками
}
using (FileSyncObjects.TableSyncer.Lock())
{
    // код с таблицами
}
using (FileSyncObjects.GoogleSpreadsheetsSyncer.Lock())
{
    // код с гугл таблицами
}

доступны Lock и HighLock, они требуют вызова Dispose, поэтому используется using.
HighLock имеет приоритет в очереди.
Так же доступны варианты для асинхронных методов - LockAsync и HighLockAsync.

 

[ZSharp]

Данный способ чуть менее производительный, но даёт чуть больше контроля

Так всё-таки лочат все шаблоны? или только текущий?

 

[Mikhail B.]

Так же доступны варианты для асинхронных методов - LockAsync и HighLockAsync.

Про это можно по подробнее?

 

[Yuriy Zymlex]

Так всё-таки лочат все шаблоны?

Да, действует на весь постер, там где используется конкретный *Syncer.

Про это можно по подробнее?

Синхронные локи опираются на ID потока, в асинхронном выполнении поток может меняться и лок может работать неправильно.

 

[timoxa949]

Данный способ чуть менее производительный, но даёт чуть больше контроля:

using (FileSyncObjects.ListSyncer.Lock())
{
//код со списками
}
using (FileSyncObjects.TableSyncer.Lock())
{
//код с таблицами
}
using (FileSyncObjects.GoogleSpreadsheetsSyncer.Lock())
{
//код с гугл таблицами
}

доступны Lock и HighLock, они требуют вызова Dispose, поэтому используется using.
HighLock имеет приоритет в очереди.
Так же доступны варианты для асинхронных методов - LockAsync и HighLockAsync.

Подскажите пожалуйста, как внести списки и таблицы в этот код? Что писать? Спасибо.

 

[Denchen]

Спасибо большое за код, подскажите новичку правильно ли понял?:
- Если в общем коде прописать:

//Объект для первого списка
"public static object ListSyncer1 = new object();
//Объект для второго списка"
"public static object ListSyncer2 = new object();"

при этом в первом шаблоне прописать:

//Лочим код изменения списка для многопотока
lock (CommonCode.ListSyncer1){
//Добавляем в список "Список 1" элемент со значением "строка"
project.Lists["Список 1"].Add("строка");
}

а во втором шаблоне прописать:

//Лочим код изменения списка для многопотока
lock (CommonCode.ListSyncer2){
//Добавляем в список "Список 2" элемент со значением "строка"
project.Lists["Список 2"].Add("строка");
}

то каждый шаблон будет ходить через свой турникет?

 

[GeGold]

Доброго времени суток , попробовал коды выше -не получилось

имеется вот такой вод код , он вставляет из переменной текст

var textcr = project.Variables["mail"].Value;
System.Windows.Forms.Clipboard.SetText(textcr);
instance.ActiveTab.KeyEvent("v","press","ctrl");//вставить текст из переменной

Из кода понятно , что ничего не лочится и при работе более одного потока буфер будет одним, в силу "опыта" работы с C# своих мозгов не хватает, подскажите что именно добавить в буфер, чтобы можно было запустить шаблон во многопотоке

Желательно лочить на уровне потока

 

[Valandersi]

Кубик получить случайную строку и положить в переменную так же лочит список?

 

[Андрейка2020]

Так что в итоге? Какой лок работать должен и нужен ли он сейчас, спустя 4 года от создания темы?

Вопрос возник, ибо есть шаблон, в котором несколько таблиц (2 на чтение строк и 2 на запись). Решил его перевести на многопоток. Вроде все правильно сделал (браузерный шаб на кубиках - чистый хардкор), а вот за неоднократно обсуждаемый лок очкую его даже запускать...

 

[Yuriy Zymlex]

Так что в итоге? Какой лок работать должен и нужен ли он сейчас, спустя 4 года от создания темы?

Вопрос возник, ибо есть шаблон, в котором несколько таблиц (2 на чтение строк и 2 на запись). Решил его перевести на многопоток. Вроде все правильно сделал (браузерный шаб на кубиках - чистый хардкор), а вот за неоднократно обсуждаемый лок очкую его даже запускать...

Данная статья касается только C#.
Блокировка в C# необходима, когда несколько действий в нём не должны выполняться одновременно.

Простые экшены сами по себе потокобезопасны, блоки экшенов - нет.

 

[Андрейка2020]

Простые экшены сами по себе потокобезопасны, блоки экшенов - нет.

То есть, если шаб на кубиках, то можно не переживать? А блоки экшенов - это которые "Свой C#-код"?

 

[Yuriy Zymlex]

То есть, если шаб на кубиках, то можно не переживать?

Да, экшены записи не будут выполнены одновременно и строки запишутся правильно (а не одна в другой).

А блоки экшенов - это которые "Свой C#-код"?

Нет, это когда вы объединяете экшены в блок (в том числе и C# экшены).

 

[Андрейка2020]

Нет, это когда вы объединяете экшены в блок (в том числе и C# экшены).

Лог в зенке

В мейкере все рОвно отрабатывает при пошаговой отработке... Беру из списка юзеров их количество, дабы обращаться к ним потом в потоке по номеру строки (ибо удаление строк и последующее добавление также срабатывает с лагами...)

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

 

[Yuriy Zymlex]

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

Если у вас первый и четвёртый экшен работает с одним списком, то вам необходимо переходить на C#, что бы объединить эти действия под один lock.

 

[volody00]

ибо удаление строк и последующее добавление также срабатывает с лагами...

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

 

[Андрейка2020]

Если у вас первый и четвёртый экшен работает с одним списком, то вам необходимо переходить на C#, что бы объединить эти действия под один lock.

Вроде победил...

А вот кубики сами

 

[bigloafer]

Данный способ чуть менее производительный, но даёт чуть больше контроля:

А где найти в документации данное, про FileSyncObjects.ListSyncer и SyncObjects.ListSyncer?

 

[Yuriy Zymlex]

А где найти в документации данное, про FileSyncObjects.ListSyncer и SyncObjects.ListSyncer?

Сейчас вы можете посмотреть только через подсказки PM, либо стороннюю IDE - это та же декомпиляция, там будет видна реализация (с документацией) публичных и открытых частей библиотек.
Создал таску, что бы в будущем не забыли добавить в C# wiki.

 

[Metrix]

100500 объектов синхронизации тоже так себе идея, ибо при таком количестве в больших шаблонах есть опасность залочить ресурс не тем объектом и "привет, баг!", который будет тяжело отловить.

Проще лочить ресурс в Зенке им же. Подчеркиваю, именно в Зенке.

Если запустите этот код, например, в 10 потоков, то в список запишется 10000 строк и ни одна не пропадет.

var list1 = project.Lists["Список 1"];

for(int i = 0; i < 1000; i++)
{
    lock(list1)
    {
        list1.Add("Поток " + System.Threading.Thread.CurrentThread.ManagedThreadId.ToString());
    }
}

Некропостинг, но как сам выяснил относительно недавно и не получил пока внятного ответа на этот вопрос, с таким локом, приведённым выше получаем и дубли и пересечения между потоками.
Такой лок НЕпотокобезопасен !!!

var startList = project.Lists["startList"];
lock(startList)
{
    //Some code
}

Так что, придётся использовать 100500 объектов синхронизации.
Прикладываю тестовый шаблон. После прогона нескольких десятков тысяч выполнений в 1000 потоков, к примеру, в конечном списке получаем дубли. Для сравнения, кубик ниже со специально созданными статическими объектами блокировки, там дублей в конечном списке нет. Ну и, естественно, в стартовом списке дубли отсутствуют, не верьте мне на слово, проверьте сами!

 

[Phoenix78]

Некропостинг, но как сам выяснил относительно недавно и не получил пока внятного ответа на этот вопрос, с таким локом, приведённым выше получаем и дубли и пересечения между потоками.
Такой лок НЕпотокобезопасен !!!

var startList = project.Lists["startList"];
lock(startList)
{
    //Some code
}

Так что, придётся использовать 100500 объектов синхронизации.
Прикладываю тестовый шаблон. После прогона нескольких десятков тысяч выполнений в 1000 потоков, к примеру, в конечном списке получаем дубли. Для сравнения, кубик ниже со специально созданными статическими объектами блокировки, там дублей в конечном списке нет. Ну и, естественно, в стартовом списке дубли отсутствуют, не верьте мне на слово, проверьте сами!

Я конечно не гуру С#, но мне кажется лочить локальную переменную не самая лучшая идея для работы в многопотоке.
Во всех примерах используются общие объекты, объявленные в общем коде или в общем классе зенки.... А у тебя в примере непойми что и сбоку бантик

 

[Roman48]

Все понятно, автор молодец!
Все же есть пару уточнений, старт шаблона, я привязал список и сделал лок списка №1, шаблон выполняется минут 15 (примерно) работает еще со списками, назовем их список №2, список№3, они тоже лакаются, проходит еще минут 10, шаблон дошел до самого конца, и надо добавить в список №1 строку, перед добавлением в список №1 надо его еще раз делать лок, ведь я уже делал лок в начале шаблона?
Но и другие потоки, тоже делали лок, списку №1 и другим спискам.

 

[Phoenix78]

Все понятно, автор молодец!
Все же есть пару уточнений, старт шаблона, я привязал список и сделал лок списка №1, шаблон выполняется минут 15 (примерно) работает еще со списками, назовем их список №2, список№3, они тоже лакаются, проходит еще минут 10, шаблон дошел до самого конца, и надо добавить в список №1 строку, перед добавлением в список №1 надо его еще раз делать лок, ведь я уже делал лок в начале шаблона?
Но и другие потоки, тоже делали лок, списку №1 и другим спискам.

Все просто. Лок не вечен. Ты просто не правильно понимаешь как он работает. Ты делаешь Лок только в одном кубике и только в одном конкретном месте , это все что между {} , как только код вышел из этих скобок, Лок перестает действовать. Или я просто не уловил, что у тебя весь шаблон в одном кубике С# и Лок действует все 15 минут ?

 

[Roman48]

Все просто. Лок не вечен. Ты просто не правильно понимаешь как он работает. Ты делаешь Лок только в одном кубике и только в одном конкретном месте , это все что между {} , как только код вышел из этих скобок, Лок перестает действовать. Или я просто не уловил, что у тебя весь шаблон в одном кубике С# и Лок действует все 15 минут ?

Ясность полная.

Можешь зайти

https://zennolab.com/discussion/threads/vyzvat-oshibku-kak.89031/

 

[bigloafer]

Ясность полная.

Лучше всего обработать пакет данных, используя временные листы - уровня кубика (не уровня проекта).
А в lock -е просто скопировать пакет данных из временного листа в лист проекта.
Так будет работать быстрее и другие потоки простаивать будут меньше.
А то многие в lock-и загоняют чуть ли не всю основную логику.

 

[Metrix]

Я конечно не гуру С#, но мне кажется лочить локальную переменную не самая лучшая идея для работы в многопотоке.
Во всех примерах используются общие объекты, объявленные в общем коде или в общем классе зенки.... А у тебя в примере непойми что и сбоку бантик

Т.е. ты не разбираешься, но решил выразить своё авторитетное мнение? Молодец, что тут скажешь
Чем тебе не нравится лок локальной переменной? Если посмотреть внимательно для чего она, то всё становится понятно. Если мы будем определять индекс строки, с которой будем работать вне лока, то однажды получим исключение "Индекс находился за пределами диапазона", потому что другой поток уже может удалить строку с этим индексом (например, она была последней). А то, что объявление переменной внутри лока, это ничего не меняет существенно.
Ты понимаешь смысл блокировки общими объектами? Если ты про SyncObjects.ListSyncer, то это общий объект для всех списков всех шаблонов, соответственно, общая очередь. Если ты про специально созданные статические объекты для блокировки public static object startListLocker = new object(); так в проекте есть кубик ниже того, что со стрелкой. Минусы подхода с блокировкой специально созданными локерами тоже есть: можно запутаться при наличии большого количества списков в шаблоне, если методы работы со списками вынесены в общий код, то дополнительно придётся прокидывать для работы с каждым списком свой локер, что также может вызвать путаницу.
По поводу бантика, посмотри внимательно пост, который процитирован и подумай ещё раз.
Доступ к объекту можно блокировать этим же самым объектом, в случае со списками/таблицами Зеннопостера это не так.

Все понятно, автор молодец!
Все же есть пару уточнений, старт шаблона, я привязал список и сделал лок списка №1, шаблон выполняется минут 15 (примерно) работает еще со списками, назовем их список №2, список№3, они тоже лакаются, проходит еще минут 10, шаблон дошел до самого конца, и надо добавить в список №1 строку, перед добавлением в список №1 надо его еще раз делать лок, ведь я уже делал лок в начале шаблона?
Но и другие потоки, тоже делали лок, списку №1 и другим спискам.

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

 

[ZSharp]

Так что, придётся использовать 100500 объектов синхронизации.

Всё правильно.
Нужно использовать статический неизменяемый локер для каждого отдельного объекта (если он нужен).
Если 10 списков, то нужно заводить 10 статических локеров, и никак не использовать сам список в качестве локера.

Инструкция блокировки — синхронизация доступа к общим ресурсам - C# reference | Microsoft Learn

Используйте инструкцию блокировки C#, чтобы гарантировать, что только один поток исключительно считывает или записывает общий ресурс, блокируя все остальные потоки, пока не завершится.

docs.microsoft.com

 

[Roman48]

Временные файлы, лочить не надо же, про временные я имею в виду, файл в внутри шаблона?

Такой список, у каждого потока свой список?

 

[ZSharp]

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

чтобы не путаться добавляйте имя объекта к локу.
Допустим есть у вас список startList, то добавьте лок с именем

public static object LockStartList = new object();

или

public static object StartListLock = new object();

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

    public class Locker
    {
        public static object startList = new object();
        public static object endList = new object();
        public static object secondList = new object();
        public static object secondTable = new object();
    }

А вызывать вот так

lock(Locker.startList)
{
     startList.Add("");
}

 

[ZSharp]

Временные файлы, лочить не надо же, про временные я имею в виду, файл в внутри шаблона?

если не важно изменение, то не надо.
Лочить, только если важно изменение данных.
Допустим вы регистрируете аккаунты, и у вас в файле лежат доступы к почтам.
Список
email1:pass1
email2:pass2
email3:pass3
email4:pass4
email5:pass5

Вам нельзя чтобы несколько потоков начали регистрировать аккаунты с одним и тем же email-ом, вот тогда нужно блокировать,
чтобы каждый поток отработал полный цикл
Цикл у нас, берём первую строку, и удаляем её после взятия.

1-й поток
1) заблокировал файл,
2) взял email, email1:pass1
3) удалил его из списка, email1:pass1
4) и снял блокировку чтобы другой поток мог сделать тоже самое.

2-й поток
1) заблокировал файл,
2) взял email, email2:pass2
3) удалил его из списка, email2:pass2
4) и снял блокировку чтобы другой поток мог сделать тоже самое.

3-й поток
1) заблокировал файл,
2) взял email, email3:pass3
3) удалил его из списка, email3:pass3
4) и снял блокировку чтобы другой поток мог сделать тоже самое.


А если не ставить блокировку, то будет вот так приблизительно:
1-й поток
взял email, email1:pass1

в этот момент
2-й поток
взял email, email1:pass1

в этот момент
3-й поток
взял email, email1:pass1

Затем в коде идёт удаление email-a (певой строки)
1-й поток
удалил его из списка, email1:pass1

в этот момент
2-й поток
удалил его из списка, email2:pass2

в этот момент
3-й поток
удалил его из списка, email3:pass3



И в итоге у вас 3 потока с одним и тем же ящиком: email1:pass1
А ящики
email2:pass2
email3:pass3
совсем не использовались, но были удалены из списка

И из этих 3-х потоков зарегистрирует аккаунт только какой-то один, кто первый успеет.