K>Большинство потокобезопасных контейнеров содержат внутри себя блокировку, то есть чтение и записть в них идет последовательно. Есть правда еще lock free контейнеры, но судя по всем тестам, такие контейнеры выигрывают у обычных поткобезопасных в очень редких случаях. Моя практика показывает, что какой-нибудь хеш-мап, который расшаривается между потоками часто является узким местом, и в итоге производительность от многопоточности не увеличивается, а скорее проседает.
Кста по хэшмапам. Вместо одного хэшмапа делаешь например массив хэшмапов
и доступ через GetHashCode() % 16. У тебя конкуренция в среднем должна уменьшиться в 16 раз, а значит и скорость
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, ksandro, Вы писали:
K>>Большинство потокобезопасных контейнеров содержат внутри себя блокировку, то есть чтение и записть в них идет последовательно. Есть правда еще lock free контейнеры, но судя по всем тестам, такие контейнеры выигрывают у обычных поткобезопасных в очень редких случаях. Моя практика показывает, что какой-нибудь хеш-мап, который расшаривается между потоками часто является узким местом, и в итоге производительность от многопоточности не увеличивается, а скорее проседает.
S> Кста по хэшмапам. Вместо одного хэшмапа делаешь например массив хэшмапов S>и доступ через GetHashCode() % 16. У тебя конкуренция в среднем должна уменьшиться в 16 раз, а значит и скорость
Кстати, идея интересная. В одном проекте на прошлой моей работе, этот хак вполне можно было заюзать. Буду иметь ввиду на будещее...
Здравствуйте, ksandro, Вы писали:
НС>>А как, по твоему, это должно выглядеть? K>Ну, в каких нибудь с и с++ все должно быть так как и есть. Эти языки и должны работать на низком уровне. Но когда придумывали java и c# уже говорили о том, что эти языки создаются с учетом многопоточности.
Кто, когда и что именно говорил?
K>Я не специалист по разработке языков программирования,
Ну а я — специалист, и при этом не очень понимаю чего ты хочешь.
K> но ИМХО понятие потока должно быть встроено в язык.
Каким образом и с какой целью?
K> Любая переменная созданная в рамках потока по умолчанию должна быть доступна только внутри этого потока.
А оно по факту так и есть. По умолчанию в java и C# поля нестатические.
K>Как по мне, то большую часть этих проверок реально реализовать в compile time
Ну есть такой borrow checker в расте. Это то чего ты хочешь?
K>>>И вторая, это то, с какой легкостью народ пишет многопоточные программы, не сильно задумываясь о последствиях (тут тормозит, давай в отдельный поток, тут надо не зависнуть при записи в большой файл, а давай еще один поток). НС>>Я наблюдаю обычно обратное. K>Ну, может поэтому тебе и так нравятся потоки
У меня нет выбора. Высоконагруженный серверный софт без потоков это не особо реалистично. Да и ограничится одним линухом я не могу, а на винде идея плодить процессы вместо потоков на редкость бредовая.
НС>>Проблем много всяких существует, в том числе и серьезных. Но это не повод лечить головную боль топором. K>Ну, почему
Я это даже обсуждать не буду.
K>, нет параллелизма нет ни гонок ни дед локов.
Еще раз, от замены потоков на процессы гонки и дедлоки никуда не деваются. Это чисто логическая проблема. Как только у тебя появляется shared state, так сразу же появляются и эти проблемы. А без shared state почти ничего полезного сделать не получится.
K> Могу точно сказать, что часто многопоточность встраивают туда, где спокойно можно обойтись без нее. K>То есть, я считаю что перед тем как использовать параллельное исполнение, надо 10 раз подумать, а так ли оно мне нужно...
Здравствуйте, ksandro, Вы писали:
S>>Но если ты используешь асинхронность тот же JavaScript работает на одном потоке, но доступ к данным из разных задач не защищен. K>Да, но там не будет race condition и deadlock! Именно это ошибки, которые могут невыявиться тестированием, и именно от них надо защищать данные при паралеллизме. Там конечно тоже все не просто, но, тестирование по крайней мере позволяет эффективно отловить баги. То есть главная проблема многопоточности исчезает!
_>>>в gui потоке, то функция parse опять же будет вызвана в gui потоке, который на момент отработки соответствующего Iocp потока вполне может быть чем-то занят. S>>Отличный пример! Не будет он ничего ждать, потому что именно для этого существует контекст S>>синхронизации(synchronizationcontext). iocp поток сделает post соотв. контексту и будет свободен. S>>За одно еще больше понял роль всяческих synchronizationcontext'ов.
_>IOCP поток естественно не будет ничего ждать. А вот "обработка данных, пришедших по сети" будет произведена только после ожиданий (причём в такой модели двойных).
Почему "обработка данных, пришедших по сети" будет произведена только после ожиданий?
Если мы говорим про UI поток, то ParseData, если я не ошибаюсь, будет выполнена в UI потоке.
Т.е. iocp поток поставит задачу (делегат) в очердь UI потоку. Если так, то тут действительно будет задержки,
плюс UI подвиснет. Я насчитал одно возможное ожидание, откуда 2 ожидания?
?
Тут уже по идее проблем никаких не должны быть. Кажется, что UI поток парсить ничего не будет.
_>Понимаешь, на самом деле все эти ждущие потоки (что в синхронном варианте, что в асинхронном) — это абсолютно не страшная вещь. И я акцентировал внимание на их наличие в асинхронном коде только по той причине, что некоторые дурачки утверждали в своих статьях, что их нет и что как раз по этому асинхронный код намного лучше. Нет, они как раз есть. Но в этом ничего страшного с точки зрения эффективности нет. А вот что реально "страшно" с точки зрения эффективности работы программы, так это суммарная задержка от момента попадания пакета в сетевую карту, до момента его обработки в прикладном коде. Потому как рассуждать о количестве выдерживаемых в минуту запросов без уточнения величины латентности могут только очень сомнительные специалисты.
Я так и не понял где будут ждущие потоки при IO... Даже iocp поток ничего не ждеть. Он привязан
к абстракции CompletionPort, которая взаимодействует с io подсистемой ОС. Данные пришли, скармливает
адрес буфера какому-нибудь доступному потоку через очередь, iocp поток затем вызывает код с этим буфером.
В очереди возможны задержки, если нет свободных iocp потоков. Как это я себе представляю.
Здравствуйте, alex_public, Вы писали:
_>Понимаешь, на самом деле все эти ждущие потоки (что в синхронном варианте, что в асинхронном) — это абсолютно не страшная вещь. И я акцентировал внимание на их наличие в асинхронном коде только по той причине, что некоторые дурачки утверждали в своих статьях, что их нет и что как раз по этому асинхронный код намного лучше. Нет, они как раз есть. Но в этом ничего страшного с точки зрения эффективности нет. А вот что реально "страшно" с точки зрения эффективности работы программы, так это суммарная задержка от момента попадания пакета в сетевую карту, до момента его обработки в прикладном коде. Потому как рассуждать о количестве выдерживаемых в минуту запросов без уточнения величины латентности могут только очень сомнительные специалисты.
For example, in Windows an OS thread makes a call to the network device driver and asks it to perform the networking operation via an Interrupt Request Packet (IRP) which represents the operation. The device driver receives the IRP, makes the call to the network, marks the IRP as "pending", and returns back to the OS. Because the OS thread now knows that the IRP is "pending", it doesn't have any more work to do for this job and "returns" back so that it can be used to perform other work.
When the request is fulfilled and data comes back through the device driver, it notifies the CPU of new data received via an interrupt. How this interrupt gets handled will vary depending on the OS, but eventually the data will be passed through the OS until it reaches a system interop call (for example, in Linux an interrupt handler will schedule the bottom half of the IRQ to pass the data up through the OS asynchronously). Note that this also happens asynchronously! The result is queued up until the next available thread is able to execute the async method and "unwrap" the result of the completed task.
Throughout this entire process, a key takeaway is that no thread is dedicated to running the task. Although work is executed in some context (that is, the OS does have to pass data to a device driver and respond to an interrupt), there is no thread dedicated to waiting for data from the request to come back. This allows the system to handle a much larger volume of work rather than waiting for some I/O call to finish.
Здравствуйте, T4r4sB, Вы писали:
TB>Какого хрена "синхронное плаванье" — это когда тётки одновременно в воде кувыркаются, а синхронное программирование — это когда процессы по очереди выполняются? Диаметрально противоположный смысл.
Потому что ты тоже путаешь асинхронность и параллельность.
Синхронное плаванье, потому что тетки должны выполнять свои движения в строго определенный, зафиксированный момент времени. Точно так же синхронный код должен выполняться строго синхронно, согласованно. А асинхронный — выполняет действия не в строго определенный момент времени, а когда получится.
Здравствуйте, ksandro, Вы писали:
K>Даже крутые гуру часто не могут написать, что-то более менее сложное без дедлоков и гонок.
Как тебе уже сказали, это больше относится к lock free алгоритмам. Но броться с этим довольно просто:
1) Не изобретать lock free алгоритмы, а пользоваться готовыми. Изобретение нетривиального lock free зачастую уровень докторской диссертации.
2) Не реализовывать эти алгоритмы с нуля, а пользоваться готовыми примитивами навроде System.Collections.Concurrent.
Здравствуйте, Sharov, Вы писали:
_>>IOCP поток естественно не будет ничего ждать. А вот "обработка данных, пришедших по сети" будет произведена только после ожиданий (причём в такой модели двойных). S>Почему "обработка данных, пришедших по сети" будет произведена только после ожиданий? S>Если мы говорим про UI поток, то ParseData, если я не ошибаюсь, будет выполнена в UI потоке. S>Т.е. iocp поток поставит задачу (делегат) в очердь UI потоку. Если так, то тут действительно будет задержки, S>плюс UI подвиснет. Я насчитал одно возможное ожидание, откуда 2 ожидания?
Первая задержка произвольного размера будет между окончанием момента обработки данных в ядре ОС и тем моментом, когда планировщик потоков выделит квант времени iocp потоку.
S>Далее, что будет, если мы код поменяем на S>
S>? S>Тут уже по идее проблем никаких не должны быть. Кажется, что UI поток парсить ничего не будет.
Это зависит от реализации Parse. )))
Ну и задержка произвольного размера будет в любом случае, просто если ты переместишь обработку из UI потока в какой-то другой, то она весьма вероятно (если компьютер не занят обработкой ещё тысяч работающих потоков) будет очень небольшой, в то время как в UI потоке она может быть больше.
Да, и кстати в случае задействования ещё одного потока сразу же встанет вопрос: а зачем мы страдали со всеми этими асинхронными приседаниями, если у нас всё равно ещё один поток используется для Parse? Не проще ли было сразу всё разместить в нём, причём с использованием банально синхронного ввода-вывода?
S>Я так и не понял где будут ждущие потоки при IO... Даже iocp поток ничего не ждеть. Он привязан S>к абстракции CompletionPort, которая взаимодействует с io подсистемой ОС. Данные пришли, скармливает S>адрес буфера какому-нибудь доступному потоку через очередь, iocp поток затем вызывает код с этим буфером. S>В очереди возможны задержки, если нет свободных iocp потоков. Как это я себе представляю.
CompletionPort — это не какая-то там абстракция, а банальная очередь. Из которой iocp потоки забирают данные с помощью БЛОКИРУЮЩЕЙ функции. Т.е. если в очереди нет сообщений о завершение каких-то операций, то поток висит в блокировке.
Здравствуйте, Sharov, Вы писали:
_>>Понимаешь, на самом деле все эти ждущие потоки (что в синхронном варианте, что в асинхронном) — это абсолютно не страшная вещь. И я акцентировал внимание на их наличие в асинхронном коде только по той причине, что некоторые дурачки утверждали в своих статьях, что их нет и что как раз по этому асинхронный код намного лучше. Нет, они как раз есть. Но в этом ничего страшного с точки зрения эффективности нет. А вот что реально "страшно" с точки зрения эффективности работы программы, так это суммарная задержка от момента попадания пакета в сетевую карту, до момента его обработки в прикладном коде. Потому как рассуждать о количестве выдерживаемых в минуту запросов без уточнения величины латентности могут только очень сомнительные специалисты. S>
S>For example, in Windows an OS thread makes a call to the network device driver and asks it to perform the networking operation via an Interrupt Request Packet (IRP) which represents the operation. The device driver receives the IRP, makes the call to the network, marks the IRP as "pending", and returns back to the OS. Because the OS thread now knows that the IRP is "pending", it doesn't have any more work to do for this job and "returns" back so that it can be used to perform other work.
S>When the request is fulfilled and data comes back through the device driver, it notifies the CPU of new data received via an interrupt. How this interrupt gets handled will vary depending on the OS, but eventually the data will be passed through the OS until it reaches a system interop call (for example, in Linux an interrupt handler will schedule the bottom half of the IRQ to pass the data up through the OS asynchronously). Note that this also happens asynchronously! The result is queued up until the next available thread is able to execute the async method and "unwrap" the result of the completed task.
S>Throughout this entire process, a key takeaway is that no thread is dedicated to running the task. Although work is executed in some context (that is, the OS does have to pass data to a device driver and respond to an interrupt), there is no thread dedicated to waiting for data from the request to come back. This allows the system to handle a much larger volume of work rather than waiting for some I/O call to finish.
Бррр, повторяю в последний раз. Вся разница между синхронным и асинхронным вводом-выводом в том, что в первом случае поток ждёт завершения одной конкретной операции ввода-вывода, а во втором случае он ждёт завершения любой операции ввода-вывода данного приложения. Соответственно в том случае, если у тебя в каждый момент времени исполняется только одна такая операция, разницы между этими подходами не будет никакой (ну не считая накладных расходов на исполнение дополнительного кода по организации очереди в асинхронном варианте).
_>Бррр, повторяю в последний раз. Вся разница между синхронным и асинхронным вводом-выводом в том, что в первом случае поток ждёт завершения одной конкретной операции ввода-вывода, а во втором случае он ждёт завершения любой операции ввода-вывода данного приложения. Соответственно в том случае, если у тебя в каждый момент времени исполняется только одна такая операция, разницы между этими подходами не будет никакой (ну не считая накладных расходов на исполнение дополнительного кода по организации очереди в асинхронном варианте).
А если их выполняются тысячи на серверах?
Все таки асинхронность нужна прежде всего для серверов.
Для десктопа и мобильных приложений это прежде всего кроссплатформенность.
Xamarin.Forms (разные контексты синхронизации итд)
Ну и удобства. По сути Task это и есть замена потока. То есть с использованием асинхронности мы забываем, что такое поток, Sleep, WhiteOne (Delay, WhiteOneAsync)
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>А если их выполняются тысячи на серверах? S> Все таки асинхронность нужна прежде всего для серверов. S>Для десктопа и мобильных приложений это прежде всего кроссплатформенность. S>Xamarin.Forms (разные контексты синхронизации итд) S>Ну и удобства. По сути Task это и есть замена потока. То есть с использованием асинхронности мы забываем, что такое поток, Sleep, WhiteOne (Delay, WhiteOneAsync)
В случае одной операции, что крайне врожденный случай, разницы действительно нет, и получается, что iopc поток будет ждать. Для серверов это не актуально.
Здравствуйте, alex_public, Вы писали:
_>Да, и кстати в случае задействования ещё одного потока сразу же встанет вопрос: а зачем мы страдали со всеми этими асинхронными приседаниями, если у нас всё равно ещё один поток используется для Parse? Не проще ли было сразу всё разместить в нём, причём с использованием банально синхронного ввода-вывода?
Тут банально какой-нибудь SOLID -- отдельно загрузка, отдельно парсинг.
S>>Я так и не понял где будут ждущие потоки при IO... Даже iocp поток ничего не ждеть. Он привязан S>>к абстракции CompletionPort, которая взаимодействует с io подсистемой ОС. Данные пришли, скармливает S>>адрес буфера какому-нибудь доступному потоку через очередь, iocp поток затем вызывает код с этим буфером. S>>В очереди возможны задержки, если нет свободных iocp потоков. Как это я себе представляю. _>CompletionPort — это не какая-то там абстракция, а банальная очередь. Из которой iocp потоки забирают данные с помощью БЛОКИРУЮЩЕЙ функции. Т.е. если в очереди нет сообщений о завершение каких-то операций, то поток висит в блокировке.
Я не согласен с такой трактовкой. Как выше я уже писал, в таком случае поток из пула (не iocp) тоже ЗАБЛОКИРОВАН, ведь он без дела тоже чего-то ждет.
Здравствуйте, alex_public, Вы писали:
MA>> Прошу понять правильно — их идея интересная, но забавно наблюдать их подходы для того что бы сломать их систему "borrowing". И оно на практике нужно ломать постоянно. Это в топку. _>Под ломать ты подразумеваешь unsafe код или что? )
Нет, я имел ввиду использование чего-то вроде Box, Cell и т.п. вместо традиционных прямых решений. Классические сильно-связные структуры на подобии деревьев реализуется ужасненько, фактически полностью нивелируя сами возможности языка, как и его преимущества перед другими. Я поэтому и сказал, что безопасность это фикция, т.к. помощи от его системы типов в таком раскладе не много, скорее мешает.
Здравствуйте, alex_public, Вы писали: _>Да, и кстати в случае задействования ещё одного потока сразу же встанет вопрос: а зачем мы страдали со всеми этими асинхронными приседаниями, если у нас всё равно ещё один поток используется для Parse? Не проще ли было сразу всё разместить в нём, причём с использованием банально синхронного ввода-вывода?
Это хорошо работает в том случае, когда у нас этот Parse и Download — один. А если мы попробуём дёрнуть десяток-другой таких задач, то у нас образуется десяток-другой потоков, которые отжирают адресное пространство и нагружают планировщик.
А с IOCP у нас потребуется O(1) потоков на ту же нагрузку — экономим адресное пространство и фактически выделяемую память для стеков.
_>CompletionPort — это не какая-то там абстракция, а банальная очередь. Из которой iocp потоки забирают данные с помощью БЛОКИРУЮЩЕЙ функции. Т.е. если в очереди нет сообщений о завершение каких-то операций, то поток висит в блокировке.
Всё верно, но этот поток ждёт "сразу все" IO-операции, а не одну-единственную.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, ksandro, Вы писали: K>Для параллельного исполнения вполне можно и нужно использовать несколько процессов а не потоков. Для того, чтоб организовать работу нескольких задач в рамках одного процесса можно и нужно использовать ассинхронность. А от тредов одни проблемы! Впринципе так оно и работало когда-то, не знаю, почему в свое время начали активно везде внедрять эти потоки, причем их активно пропагандировали еще до массового появления многоядерных процессоров.
О, добро пожаловать в Гармонично Взаимодействующие Процессы, обратно к Дийкстра и Ко.
Потоки начали активно пропагандировать вместе с вытесняющей многозадачностью; преимущества понятны — накладные расходы на IPC во всех архитектурах времён Дийкстры были запретительно высоки.
Банальная штука — декомпрессия архива. Пилим три процесса: один читает, другой разжимает, третий пишет. Если у нас нет общего адресного пространства, то оформление общения в виде "пересылки сообщений" навзнич убъёт весь выигрышь от асинхронности. А если есть — добро пожаловать в потоки с их проблемами.
Есть и ещё один вариант — Эрланг, но в обсуждаемые времена никакого Эрланга не было.
Кроме того, гармонические процессы — не панацея. Ну да, покорраптить чужую память нельзя; дедлок словить нельзя.
Но можно запросто словить livelock, а он с т.з. пользователя ничуть не лучше.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Это хорошо работает в том случае, когда у нас этот Parse и Download — один. А если мы попробуём дёрнуть десяток-другой таких задач, то у нас образуется десяток-другой потоков, которые отжирают адресное пространство и нагружают планировщик. S>А с IOCP у нас потребуется O(1) потоков на ту же нагрузку — экономим адресное пространство и фактически выделяемую память для стеков.
динственную.
В смысле отжирают? Если не ошибась,они уже отожрали в момент старта приложения, по факту своего нахождения в пуле.
А вот если пул плодит еще потоков, т.е. ему мало, тогда да.
Здравствуйте, Sharov, Вы писали:
_>>CompletionPort — это не какая-то там абстракция, а банальная очередь. Из которой iocp потоки забирают данные с помощью БЛОКИРУЮЩЕЙ функции. Т.е. если в очереди нет сообщений о завершение каких-то операций, то поток висит в блокировке. S>Я не согласен с такой трактовкой. Как выше я уже писал, в таком случае поток из пула (не iocp) тоже ЗАБЛОКИРОВАН, ведь он без дела тоже чего-то ждет.
Во-первых это не трактовка, а факты из объективной реальности. А во-вторых, ну да, потоки в пуле заблокированы до момента прихода новой задачи. И после её завершения тоже уходят в блокировку. Что в этом такого странного? Собственно это нормальное поведение потоков, для которого в ОС предусмотрено множество разных примитивов синхронизации.
