N>>Я вот хотел сделать (на Core 5.0) чтобы коллбэки на чтение сокета срабатывали всегда в нужной нитке. Не получается: мне их, фактически, принудительно загоняют в какой-то пул, который я не просил создавать, и я должен ещё думать о мьютексах, чтобы применить их данные. А тут, наоборот, какая-то самоблокировка на одной нитке непонятно на чём. S> Ну тебе в данной нитке нужно организовать очередь и пихать в неё свои калбеки. Поток опять же ставить на ожидантие и при постановке в очередь выставлять эвент в сигнальное состояние.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
N>>>Я вот хотел сделать (на Core 5.0) чтобы коллбэки на чтение сокета срабатывали всегда в нужной нитке. Не получается: мне их, фактически, принудительно загоняют в какой-то пул, который я не просил создавать, и я должен ещё думать о мьютексах, чтобы применить их данные. А тут, наоборот, какая-то самоблокировка на одной нитке непонятно на чём. S>> Ну тебе в данной нитке нужно организовать очередь и пихать в неё свои калбеки. Поток опять же ставить на ожидантие и при постановке в очередь выставлять эвент в сигнальное состояние.
S>Кстати да, не проще ли все организовать через блокирующую коллекцию? Пишет кто хочет, читает один поток.
S>>Либо использовать контекст синхронизации S>>https://docs.microsoft.com/ru-ru/dotnet/standard/parallel-programming/how-to-specify-a-task-scheduler-in-a-dataflow-block
S>Интересная идея, но тут скорее выгода, если рабочих потоков может быть больше одного, а для одного городить огород S>смысла нет. Хотя для UI сгородили.
Ну так разговор то о том, что нужно выполнить калбек в определенном потоке.
Ну организовать то свою очередь сообщений не сложно, тот же эвент WaitOne с таймаутом на всякий случай.
Контекс синхоронизации это для ленивых. Ты можешь его сам создать
if (SynchronizationContext.Current == null)
SynchronizationContext.SetSynchronizationContext(new WindowsFormsSynchronizationContext());
или System.Windows.Threading.DispatcherSynchronizationContext
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
N>>2. При высокой цене переключения между нитками внутреннее переключение (шедулером на границе awaitʼа) будет в разы дешевле переключения через ОС. S> Вот спасибо! Все таки дешевле!
Ну так я никогда не возражал, что при описанном условии (дорогом переключении) лучше его обходить.
Но мне, к счастью, не приходится работать с Windows.
И то, что я говорил, не сводится только к цене переключения (а ты почему-то остальные темы обходишь).
S> Ну давай возьмем типичный сервер. БОльшая часть задач сводится к вызову асинхронным методов а именно запрос к базе данных (не локальной), запрос к сайту, к файлу итд. S>Выделять для каждого запроса отдельный поток не имеет смысла (тут и затраты на создание потока или держать пул огромного размера). S>Как правило эти задачи небольшие. S> Отдельный поток стоит выделять для длительных задач LongRunning
Пока кэпствуешь, ok.
S> То есть смысла в выделении потоках на задачу нет. Есть смысл использовать пул потоков. Что было кстати в ранних версиях вэб сервисов ASP.Net. S>Тогда тоже были и асинхронные делегаты (BeginInvoke() и EndInvoke()) и ThreadPool. Но в том же сервисе вызов вэб метода был синхронным, то есть привязан к одному потоку. То есть внутри то можно было использовать калбеки и прочее, но поток морозился на эвенте
Эти все подробности не знаю и они мне как-то побоку.
S>То есть например когда мы в базе данных что то активно меняем, и запросов на чтение как раз и будут ждать пока не закончится запись. S>Конечно можно по максимуму съузить блокировки, но не всегда это возможно.
Так какое отношение это всё имеет, например, к качеству управления локами?
Здравствуйте, Serginio1, Вы писали:
N>>Я вот хотел сделать (на Core 5.0) чтобы коллбэки на чтение сокета срабатывали всегда в нужной нитке. Не получается: мне их, фактически, принудительно загоняют в какой-то пул, который я не просил создавать, и я должен ещё думать о мьютексах, чтобы применить их данные. А тут, наоборот, какая-то самоблокировка на одной нитке непонятно на чём.
S> Ну тебе в данной нитке нужно организовать очередь и пихать в неё свои калбеки. Поток опять же ставить на ожидантие и при постановке в очередь выставлять эвент в сигнальное состояние. S>Либо использовать контекст синхронизации S>https://docs.microsoft.com/ru-ru/dotnet/standard/parallel-programming/how-to-specify-a-task-scheduler-in-a-dataflow-block
Ага, ага. Вы это серьёзно вместе с автором статьи?
Первый же пример
>> return 1 + await CountRecursivelyAsync(count — 1); >> Консоль упадет со StackOverflowException. Печаль!
Какой нафиг StackOverflowException, откуда тут стек взялся? Или это специфика того, что компилятор делает из awaitʼа рекурсивного вызова той же функции? "Ну нафиг" (tm).
Тут не шедулеры надо сравнивать, а вначале этот бред исправлять.
Здравствуйте, netch80, Вы писали:
S>>https://habr.com/ru/post/336000/ N>Ага, ага. Вы это серьёзно вместе с автором статьи? N>Первый же пример >>> return 1 + await CountRecursivelyAsync(count — 1); >>> Консоль упадет со StackOverflowException. Печаль! N>Какой нафиг StackOverflowException, откуда тут стек взялся? Или это специфика того, что компилятор делает из awaitʼа рекурсивного вызова той же функции? "Ну нафиг" (tm).
1)Что значит откуда стек взялся в контексте потоков? Правильно было бы сказать откуда StackOverflowException в контексте потоков, а не стек.
2)Скорее всего код выполнялся синхронно, т.е. в одном потоке. В .net есть оптимизация, которая при отдаче
управления(потока) проверяет "а не завершилась ли задача", и если да, то в том же потоке запустит продолжение,
т.е. рекурсивный вызов. Отсюда и исключение.
Здравствуйте, netch80, Вы писали:
S>>Конечно можно по максимуму съузить блокировки, но не всегда это возможно.
N>Так какое отношение это всё имеет, например, к качеству управления локами?
А их как таковых и нет если использовать задачи. Реальными блокировками уже занимается SQL он же дает отлуп если занят
и солнце б утром не вставало, когда бы не было меня
N>Честно, я совсем не понимаю, зачем вначале конструировать бешеного быка, чтобы потом искать методы его успокоения, когда надо проехаться на автобусе с таким "двигателем" под капотом.
То есть у тебя проблема создать поток а в нем организовать очередь и её выборку это бешенный бык) там 15 строчек кода то всего.
Про контекст синхронизации это для ленивых которым влом 15 строчек когда набрать
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, gandjustas, Вы писали:
T>>А почему, собственно, потоки операционной системы не могут быть столь же эффективны, как и горутины? То есть почему разработчики OS тоже не могут сделать динамический стек и другие оптимизации?
G>1) Переключение контекста не бесплатное
А у Go -- бесплатное?
G>2) Каждый поток кушает 1МБ под стек минимум
Адресного пространства, а не стека. Памяти на стек тратится, минимум, килобайт 8 думаю.
G>В основном потому что ОС не знает чем будет заниматься поток и делает многое "по умолчанию".
Можно подумать, Go знает. Часто этого и сам поток не знает.
G>В Винде уже давно есть возможность создавать пулы потоков, очереди задач, ожидания IO и таймеров, что позволяет иметь много потоков в программе при минимуме потоков в ОС.
В Linux тоже make_context и switch_context были с доисторических времён. Когда ещё потоков наверное не было.
Здравствуйте, fk0, Вы писали:
fk0>Здравствуйте, gandjustas, Вы писали:
T>>>А почему, собственно, потоки операционной системы не могут быть столь же эффективны, как и горутины? То есть почему разработчики OS тоже не могут сделать динамический стек и другие оптимизации?
G>>1) Переключение контекста не бесплатное fk0> А у Go -- бесплатное?
Гораздо более дешевое, чем в ОС, примерно на два десятичных порядка.
G>>2) Каждый поток кушает 1МБ под стек минимум fk0> Адресного пространства, а не стека. Памяти на стек тратится, минимум, килобайт 8 думаю.
Сколько реально тратится — зависит от того как написан код. Может оказаться довольно много в сумме.
Когда еще не было async\await в C# я переписал один сервер с использования потока на соединение на асинхронные вызовы и очередь. Получил экономию около 200мб, что составляло четверть расходуемой памяти.
G>>В основном потому что ОС не знает чем будет заниматься поток и делает многое "по умолчанию". fk0> Можно подумать, Go знает. Часто этого и сам поток не знает.
Конечно знает. Я не знаю как точно в Go это устроено, но компилятор C# прекрасно определяет какие перменные нужны в продолжении.
G>>В Винде уже давно есть возможность создавать пулы потоков, очереди задач, ожидания IO и таймеров, что позволяет иметь много потоков в программе при минимуме потоков в ОС.
fk0> В Linux тоже make_context и switch_context были с доисторических времён. Когда ещё потоков наверное не было.
Это типа cooperative multitasking? Увы в рукопашную его нигде практически не используют.
Здравствуйте, mrTwister, Вы писали:
T>А почему, собственно, потоки операционной системы не могут быть столь же эффективны, как и горутины? То есть почему разработчики OS тоже не могут сделать динамический стек и другие оптимизации?
Горутины, как и другие средства асинхронного программирования — это кооперативная многозадачность, не вытесняющая. Это существенно быстрее, но плохо написанный "поток" может залочить систему целиком.
Здравствуйте, scf, Вы писали:
scf>Горутины, как и другие средства асинхронного программирования — это кооперативная многозадачность, не вытесняющая. Это существенно быстрее, но плохо написанный "поток" может залочить систему целиком.
Нет, горутины — это давно уже вытесняющая многозадачность, так как переключение контекста происходит по внешнему таймеру независимо от воли переключаемой горутины (кроме некоторых выделенных случаев типа выполнения системного вызова и др.)
Здравствуйте, mrTwister, Вы писали:
T>Нет, горутины — это давно уже вытесняющая многозадачность, так как переключение контекста происходит по внешнему таймеру независимо от воли переключаемой горутины (кроме некоторых выделенных случаев типа выполнения системного вызова и др.)
Можно ссылку? Не смог нагуглить сходу, пишут "The Go Runtime Scheduler does cooperative scheduling,"
T>А почему, собственно, потоки операционной системы не могут быть столь же эффективны, как и горутины?
Потому что они обеспечивают изоляцию другого порядка.
Если что, горутины — это бледная пародия на модель выполнения Erlang, полученная в силу NIH-синдрома и неумения или нежелания разбираться в уже существующих концепциях. Чтобы понять более фундаментальные основы, и то, как оно, надеюсь, будет в итоге доступно большинству, рекомендую взглянуть как раз на Erlang.
Здравствуйте, SkyDance, Вы писали:
T>>А почему, собственно, потоки операционной системы не могут быть столь же эффективны, как и горутины?
SD>Потому что они обеспечивают изоляцию другого порядка.
SD>Если что, горутины — это бледная пародия на модель выполнения Erlang, полученная в силу NIH-синдрома и неумения или нежелания разбираться в уже существующих концепциях. Чтобы понять более фундаментальные основы, и то, как оно, надеюсь, будет в итоге доступно большинству, рекомендую взглянуть как раз на Erlang.
По сообщению уже можно было понять, кто его написал, не смотря в заголовки
А как по-вашему — Тони Хоар писал свой фундаментальный труд уже подсмотрев Erlang через машину времени и написав бледную пародию, или всё-таки кто на ком стоял — оказалось наоборот?
N>А как по-вашему — Тони Хоар писал свой фундаментальный труд уже подсмотрев Erlang через машину времени и написав бледную пародию, или всё-таки кто на ком стоял — оказалось наоборот?
Сэр Чарльз, боюсь, не был среди авторов велосипеда "горутина".
Он предложил математическую модель "акторов". Теоретические основы. Которые на практике были воплощены и до Erlang'а, скажем, в LISP, частично в Smalltalk. Но как afterthought. В отличие от Erlang, который был как раз спроектирован вокруг данной концепции. Поэтому программы, которые хорошо ложатся на эту модель, выглядят очень кратко, и, не побоюсь этого слова, красиво.
Go же идет "от сохи", с ушами привычной императивщины отовсюду. Что, конечно, проще преподать как некое "усовершенствование всего того, что вы уже знаете". Знакомый синтаксис, старые баги, и вообще все то, к чему мы с детства, с Бейсика или Паскаля, привыкли. Та самая "более быстрая лошадь", которую Генри Форд не хотел давать своим покупателям.
Это и ведет к тяжеловесности и отсутствии красоты в коде. Что мешает разобраться в фундаментальных основах. Половинчатые решения вроде "хотите message passing, хотите — shared memory" только затрудняют понимание концепций. С учетом того, насколько позже Go появился, его вторичность очевидна. Именно что "еще один язык в куче других одинаковых".
Здравствуйте, netch80, Вы писали:
N>>>И кто пустит посторонний код в ядро? C>>Можно eBPF использовать
N>Я не уверен, что на нём можно написать шедулер. Хотя если есть возможность оперирования с конкретными байтиками и всё уложить на эту логику, то может пойти...
