B>>Оба запроса кидаются в очередь хозяину карты. Хозяин их вычитывает из очереди и выполняет. Лочить карту ему не нужно, ведь он ее владелец — никто другой с ней не работает.
O>Но тогда очередь должна быть потокобезопасной, т.е. лочим не карту а очередь. O>Например 2 потока пытаются одновременно добавить записи в очередь, а хозяин еще и читать ее пытается, если там не будет критической секции то может получиться непредсказуемое поведение.
Задачи эксклюзивного чтения или записи в очередь (или обращения к другому ресурсу), а также производитель-потребитель решаются стандартными средствами, которые есть в любом языке (mutex, условная переменная). Если же таких очередей и других ресурсов становится много и они зависят друг от друга, вот тогда и возникает потребность в какой-то "архитектуре" и фреймворках, реализующих эту более высокоуровневую абстракцию. Иначе тупики, гонки и глобальные блокировки, превращающие многопоточное приложение в приложение на питоне. И самое главное, при любом изменении приходится заново продумывать ВСЕ сложные зависимости, которые есть в приложении (иначе тупики, гонки и другие гейзенбаги многопоточки утекут в продакшн).
И, кстати, все (или почти) архитектуры многопоточной обработки строятся на очередях (каналах) и обработчиках этих очередей с эксклюзивным владением данными в очереди (иначе все те же зависимости по данным и шанс поймать deadlock).
Здравствуйте, Masterspline, Вы писали:
B>>>Оба запроса кидаются в очередь хозяину карты. Хозяин их вычитывает из очереди и выполняет. Лочить карту ему не нужно, ведь он ее владелец — никто другой с ней не работает.
O>>Но тогда очередь должна быть потокобезопасной, т.е. лочим не карту а очередь. O>>Например 2 потока пытаются одновременно добавить записи в очередь, а хозяин еще и читать ее пытается, если там не будет критической секции то может получиться непредсказуемое поведение.
M>Задачи эксклюзивного чтения или записи в очередь (или обращения к другому ресурсу), а также производитель-потребитель решаются стандартными средствами, которые есть в любом языке (mutex, условная переменная).
Не совсем я понял твою мысль, инструменты то да есть, но автор я так предполагаю хочет избавится от "лочек", т.е. тех самых инструментов синхронизации.
"Карта" по сути это тот же список элементов которые содержатся в "клетке", т.е. я не вижу принципиальной разницы между работой с очередью или списком из разных потоков , в обоих случаях требуется синхронизация.
Наличие в библиотеке готовых потокобезопасных очередей или списков не значит что там не будут использоваться эти самые инструменты синхронизации.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Здравствуйте, Masterspline, Вы писали:
B>>>>Оба запроса кидаются в очередь хозяину карты. Хозяин их вычитывает из очереди и выполняет. Лочить карту ему не нужно, ведь он ее владелец — никто другой с ней не работает.
O>>>Но тогда очередь должна быть потокобезопасной, т.е. лочим не карту а очередь. O>>>Например 2 потока пытаются одновременно добавить записи в очередь, а хозяин еще и читать ее пытается, если там не будет критической секции то может получиться непредсказуемое поведение.
M>>Задачи эксклюзивного чтения или записи в очередь (или обращения к другому ресурсу), а также производитель-потребитель решаются стандартными средствами, которые есть в любом языке (mutex, условная переменная).
O>Не совсем я понял твою мысль, инструменты то да есть, но автор я так предполагаю хочет избавится от "лочек", т.е. тех самых инструментов синхронизации.
Насколько я понял, автор не пытается уйти от блокировок. Он ищет более высокоуровневые архитектурные подходы к разработке многопоточного кода. Моя мысль была в том, что очереди можно сделать на mutex, но если архитектура усложняется, т.е. для разных операций нужно блокировать несколько разных объектов (и в результате нужно продумать все варианты, кто и когда может заблокировать данный объект, что слишком сложно), то нужно переходить на более высокие абстракции. Но на более низком уровне они будут основаны на тех же mutex и других примитивах.
Такие архитектуры: CSP (как в Go, где общение идет через каналы, т.е. те же очереди), конвейер, который автор сам придумал в результате. Мегамонстр на акторах (который подходит для задач SCADA, где все объекты долгоживущие и каждый со своим состоянием, и который слишком сложен и не нужен, если у объектов не будет своих состояний или объекты часто создаются и уничтожаются, т.е. не подходит к задаче автора). Наверняка есть и другие.
Здравствуйте, okon, Вы писали:
O>"Карта" по сути это тот же список элементов которые содержатся в "клетке", т.е. я не вижу принципиальной разницы между работой с очередью или списком из разных потоков , в обоих случаях требуется синхронизация.
Работа с очередью — быстрые операции по перекладыванию локальных данных, работа с картой может обновлять связанные с ней объекты, лазить в базу, писать логи и делать ещё 100500 вещей. Синхронизация очереди будет дешелве и по времени и по сложности реализации.
O>Наличие в библиотеке готовых потокобезопасных очередей или списков не значит что там не будут использоваться эти самые инструменты синхронизации.
В многопоточном приложении без синхронизации не получится (lock-free очереди тоже синхронизируются), но можно минимизировать время выполнения синхронного кода и изолировать этот код от других синхронных мест (чтобы гарантировать отсутвие взаимных блокировок).
O>>Наличие в библиотеке готовых потокобезопасных очередей или списков не значит что там не будут использоваться эти самые инструменты синхронизации. XMK>В многопоточном приложении без синхронизации не получится (lock-free очереди тоже синхронизируются), но можно минимизировать время выполнения синхронного кода и изолировать этот код от других синхронных мест (чтобы гарантировать отсутвие взаимных блокировок).
Зачем вы рассказываете человеку, который не разобрался с многопоточкой на блокировках какие-то сложности про lockfree?
Pzz>В Go несколько больше, чем тред-пул. Например, если запустить Go 100500 потоков, которые что-то делают с сетью, то операционная система будет видеть количество потоков, сравнимое с количеством процессоров, и ожидание готовности будет осуществляться наиболее подходачим для системы опразом — через completion port в венде, через epoll в линухе и т.п.
причем тут Go... прога написанная на любом языке, будет обращяться к ОС за созданием потока, как будет создан поток и сколько он ресурсов сожрет это от языка мало зависит (исключим недоделки оптимизации компиляторов).
на чистом С можно создать 100500 потоков , винда выделил только один. Но это конечно зависит от того что делает поток. Если одного потока не хватит для обслуживания 100500 запросов, винда создаст дополнительный.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Basil2, Вы писали:
B>>Например, я как-то сделал класс для многопоточного счетчика через операцию ++. А тимлид сказал что так нельзя, ибо стандартная сигнатура операции ++ не позволяет корректно вернуть результат в многопоточной среде, и надо использовать функцию-член типа inc(). Вот таких нюансов хотелось бы (не в смысле С++, а в смысле принципов работы с переменными).
Pzz>Интересно, а тим-лид как-то обосновал, почему ++ не подходит, или это его суеверия не велят так делать?
Здравствуйте, MScanner, Вы писали:
MS>причем тут Go... прога написанная на любом языке, будет обращяться к ОС за созданием потока, как будет создан поток и сколько он ресурсов сожрет это от языка мало зависит (исключим недоделки оптимизации компиляторов).
Стандартный сишный рантайм на любой популярной операционной системе отображает потоки C/C++ на потоки операционной системы 1:1, и это, на самом деле, очень сложно сделать по-другому. А вот стандартный рантайм Go использует один поток операционной системы для обслуживания большого количества потоков Go. И когда поток Go засыпает в ожидании завершения какой-либо блокирующейся операции, то обслуживавший его поток операционной системы не засыпает вместе с ним, а переключается на обслуживание другого потока Go (если подходящий ничейный поток найдется).
MS> на чистом С можно создать 100500 потоков , винда выделил только один. Но это конечно зависит от того что делает поток. Если одного потока не хватит для обслуживания 100500 запросов, винда создаст дополнительный.
На чистом C вообще нельзя создать никаких потоков, поток можно создать, позвав соответствующую функцию. И все пригодные для этого функции в венде в конечном итоге позовут CreateThread, которая создаст поток операционной системы.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, MScanner, Вы писали:
MS>>причем тут Go... прога написанная на любом языке, будет обращяться к ОС за созданием потока, как будет создан поток и сколько он ресурсов сожрет это от языка мало зависит (исключим недоделки оптимизации компиляторов).
Pzz>А вот стандартный рантайм Go использует один поток операционной системы для обслуживания большого количества потоков Go.
рантайм Go вызывает соответсвующие функции ОС . чтобы юзать один поток для выполнения большого кол-ва запросов.
на С++ как бы есть библиотеки (boost, pplx) которые делают тоже самое (тока немного буковки другие) , в конечном счете это ведет к вызову функций ОС
C — также можно вызвать напрямую функцию ОС (winAPI например) — вот цикл из 1000 итераций в каждой итерации хотим чтобы функция F выполнялись параллельно. ОС в зависимости от функции F может на 1000 паралельных вызовов выделить 1, 50 , 100, 1000 потоков .
Рантайм любого языка дергает нужные функции ОС,
MS>> на чистом С можно создать 100500 потоков , винда выделил только один. Но это конечно зависит от того что делает поток. Если одного потока не хватит для обслуживания 100500 запросов, винда создаст дополнительный.
Pzz>На чистом C вообще нельзя создать никаких потоков, поток можно создать, позвав соответствующую функцию. И все пригодные для этого функции в венде в конечном итоге позовут CreateThread, которая создаст поток операционной системы.
если с этой точки зрения смотреть — ни один язык не может создавать никаких потоков. Так как это задача ОС.
CreateThread — позовет или нет зависит от программера. в ОС (я про винду) есть не только CreateThread для параллельного исполнения кода
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, XuMuK, Вы писали:
XMK>>(lock-free очереди тоже синхронизируются)
S>А можно подробнее, а то lock-free и синхронизация взаимоисключающи?
Пардон, неточно выразился. Имелась в виду логическая синхронизация выполнения кода в разных потоках.
Здравствуйте, XuMuK, Вы писали:
XMK>Здравствуйте, okon, Вы писали:
O>>"Карта" по сути это тот же список элементов которые содержатся в "клетке", т.е. я не вижу принципиальной разницы между работой с очередью или списком из разных потоков , в обоих случаях требуется синхронизация. XMK>Работа с очередью — быстрые операции по перекладыванию локальных данных, работа с картой может обновлять связанные с ней объекты, лазить в базу, писать логи и делать ещё 100500 вещей. Синхронизация очереди будет дешелве и по времени и по сложности реализации.
Наверно соглашусь, но все же замечу 100500 вещей особенно запись в базу и лог можно делать асинхронно.
O>>Наличие в библиотеке готовых потокобезопасных очередей или списков не значит что там не будут использоваться эти самые инструменты синхронизации. XMK>В многопоточном приложении без синхронизации не получится (lock-free очереди тоже синхронизируются), но можно минимизировать время выполнения синхронного кода и изолировать этот код от других синхронных мест (чтобы гарантировать отсутвие взаимных блокировок).
наличие возможности реализации lock-free очереди наверное единственный для меня весомый аргумент , так понимаю связный список тоже можно lock-free сделать судя по реализации которую приводят ?
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, XuMuK, Вы писали:
XMK>> Имелась в виду логическая синхронизация выполнения кода в разных потоках.
S>А енто что за зверь такой?
Например, поток, который изменяет глобальную карту, не будет работать пока не придут данные о действиях игрока. И наоборот, поток, который обеспечивает взаимодействие с игроком будет ждать изменений в глобальной карте, чтобы отослать их клиенту. Как этот механизм ожидания будет реализован уже не важно.
Здравствуйте, okon, Вы писали:
O>Здравствуйте, XuMuK, Вы писали:
O>наличие возможности реализации lock-free очереди наверное единственный для меня весомый аргумент
lock-free это деталь реализации, на уровне логики приложения не важно будет использована lock-free очередь или список с мьютексами и условными переменными.
Принципиальный вопрос это выбор данных, доступ к которым надо синхронизировать и разделение работы с данными по потокам. Можно обрабатывать данные о действиях пользователя в одном потоке и синхронизировать обращения к карте, а можно обрабатывать действия с картой в одном потоке, и синхронизировать работу с данными пользователя. На мой взгляд второй вариант будет предпочтительнее, т.к. карта здесь выступает в качестве глобальной переменной к которой обращаются все пользователи, а данные от пользователя и к пользователю локализованы в обработчике соединения.
O>так понимаю связный список тоже можно lock-free сделать судя по реализации которую приводят ?
Можно готовый взять, но речь не об этом.
Здравствуйте, okon, Вы писали:
O>Но тогда очередь должна быть потокобезопасной, т.е. лочим не карту а очередь. O>Например 2 потока пытаются одновременно добавить записи в очередь, а хозяин еще и читать ее пытается, если там не будет критической секции то может получиться непредсказуемое поведение.
+100500
Критическая секция или мьютекс — здесь просто необходим для синхронизации потоков!
Здравствуйте, Masterspline, Вы писали:
M>Это означает, что каждый владыка мира может работать только на одном потоке.
Да, но это проблема только если мир один, как в WoW или в Eve. А если это сессионка, типа WoT, то там одновременных миров заведомо больше чем ядер, так что по любому будет не хуже.
M>Я бы это реализовал на корутинах C++. Одна корутина читает и десериализует события, ставит запрос к владыке мира в очередь. Владыки работают на своем пуле. Далее корутина, которая записывает ответ от владыки в сеть.
При всей моей любви к С++, многопоточность там сделали очень угребищно. Std::thread c его terminate и std::async, которой вовсе не асинк даже в случае с std::async(std::async::async), это просто что-то с чем-то. Как-то не хочется в эту трясину лезть.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, okon, Вы писали:
O>Но тогда очередь должна быть потокобезопасной, т.е. лочим не карту а очередь.
Само собой. Но такая очередь — это уже готовая и простая конструкция, ее можно просто взять и использовать, почти без шансов накосячить.
O>Например 2 потока пытаются одновременно добавить записи в очередь, а хозяин еще и читать ее пытается, если там не будет критической секции то может получиться непредсказуемое поведение.
Скорее всего там еще и condition variable будет.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, MScanner, Вы писали:
B>>Я понимаю. Встроенный тред-пул это удобно — интересно, есть ли в Rust нечто подобное. MS>вы хотите этим сказать, что прога написанная на Rust создает потоки без ведома ОС ?
В Rust еще не знаю, а в Go это типа суперфича языка. Ты хоть тысячи потоков создаешь, а Go сам раскладывает их в несколько потоков операционки.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
