Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, Pavel Dvorkin, Вы писали:

А>М-да Как-бы воспринял Вас как автора поста Не обижайтесь, если что, просто пытаюсь одновременно заниматься тремя разными делами и при этом ещё пить пиво В общем, отнеситесь снисходительно к этой путанице

Классическая задача на потоки.

SetThreadPriority(hThreadDrinkingBeer,THREAD_PRIORITY_HIGHEST);
SetThreadPriority(hThreadFirstTask,THREAD_PRIORITY_ABOVE_NORMAL);
SetThreadPriority(hThreadSecondTask,THREAD_PRIORITY_NORMAL);
SetThreadPriority(hThreadThirdTask,THREAD_PRIORITY_BELOW_NORMAL);

Здравствуйте, jedi, Вы писали:

J> А еще, я не понимаю почему мне не дают создать свой ThreadPool и привязывать хендлы к нему.

Может потому, xто слишком многие пытались использовать его не по назначению? Например, создавая по несколько экзэмпляров порта вместо одного, вот авторы NET и решили:"Да ну их всех нафиг, сами всё разрулим!"

Здравствуйте, <Аноним>, Вы писали:

А>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Это я не понял. Предположим, мы имеем N портов и 1 поток на порту. Если бы было ровно наоборот, то PostQueuedCompletionStatus отправлялось бы в единственный порт, а уж он пусть выбирает поток. Но у нас N портов, так что выбор порта (==потока) будет делать некий иной код. Например, вести учет зантяых/свободных потоков и выбирать один из них. Так что будут задания в очередях или нет — зависит от того, как этот код работает. В сущности то, что предлагает jedi, есть просто ручное управление потоками. Я поэтому и предложил QuueUserAPC, там поток явно указывается.

А>Но Вы же выбираете порт в момент создания девайса, верно? Как Вы можете заранее предсказать, с каим девайсом будет более "плотная" работа, а какой будет больше простаивать? Вот возьмём к примеру сокеты. Вам подключился клиент, Вы так или иначе получили экзэмпляр сокета и должны привязать его к определённому порту. Откуда Вы знаете, что данный клиент будет отправлять много запросов или наоборот, мало? Может он запросит у Вас 100 байт данных, которые лежат у Вас в кэше сервера, и задумается над ними часа на два. А потом проснётся и начнёт сыпать по 10 тяжёлых запросов каждую секунду. А ведь привязка может осуществляться вообще до подключения клиента, хоть тот-же AcceptEx взять, или именованные пайпы. Тогда вообще никаких шансов угадать.

Забудьте о втором порте и потоке. Он в другом процессе, на другой машине. Я просто хочу зеленые потоки

А>По сути то, что Вы описываете, и есть функции порта, а Вы пытаетесь взять их на себя, но при этом обладете гораздо меньшими возможностями, чем порт. Возникает вопрос — зачем тогда порт? С тем-же успехом можно обойтись без него, вызывая в потоке WaitForMultipleObjects, это даже даст больше возможностей по управлению процессом.

Ничего я не пытаюсь брать на себя. Порт — всего лишь способ асинхронного ввода-вывода. То что он берет на себя обязанности лоад-балансера когда потоков больше одного — хорошо. Но оно мне не надо.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, jedi, Вы писали:

J>>Угу, в этом и проблема. А еще, я не понимаю почему мне не дают создать свой ThreadPool и привязывать хендлы к нему.

PD>Ну это-то понятно.

PD>The thread pool is created the first time you call QueueUserWorkItem or BindIoCompletionCallback, or when a timer-queue timer or registered wait operation queues a callback function.

PD>Нет в Windows создания этого самого пула. Создается он автоматом при условии выше. И один он на весб процесс. И привязывать к нему потоки нельзя. Он сам умный, он ими управляет как надо.

PD>В Висте появились новые пулы (см. CreateThreadpool), но не могли же авторы .Net ограничиться Вистой.

Мне не нужен пул вообще, я просто хочу эффективный ввод-вывод в пределах одного потока без всяких синхронизаций. Если мне понадобится больше потоков — будет лоад балансер.
И не совсем обязательно этим потокам жить в одном процессе и на одной машине.

Ладно, дискуссия становится неинтересной. Мы уже выснили, что в .NET того что я хочу нет. А что и где есть — это тема для отдельной беседы.

Здравствуйте, jedi, Вы писали:

А>>По сути то, что Вы описываете, и есть функции порта, а Вы пытаетесь взять их на себя, но при этом обладете гораздо меньшими возможностями, чем порт. Возникает вопрос — зачем тогда порт? С тем-же успехом можно обойтись без него, вызывая в потоке WaitForMultipleObjects, это даже даст больше возможностей по управлению процессом.

J>Ничего я не пытаюсь брать на себя. Порт — всего лишь способ асинхронного ввода-вывода. То что он берет на себя обязанности лоад-балансера когда потоков больше одного — хорошо. Но оно мне не надо.

И еще. То что Вы рассказывает (да и сама идея тред пула) хорошо работает для серверов где клиенты независимы.
Теперь представьте себя что-то типа игрового сервера, где все взаимодействуют со всем. Все эти выгоды виндового тред пула мгновенно испарятся от офигительной тучи блокировок.
Ну и, я вас уверею, в более-менее нетривиальном сервере с fine-grained locks будет жить зоопарк багов синхронизации (видел своими глазами).

Так что, не надо мне лоад балансинга. Лоад балансинг есть свой. И клиенты будут раскидываться по серверам какими-то логическими группами. А будут эти сервера жить в одном процессе и разных потоках, в разных процессах и на разных машинах — это вообще неважно.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>. Но у меня был один. Впрочем, я порт не использовал, а просто QueueUserAPC. Схема простая — привязка потока при появлении запроса, отвязка при окончании обработки. В общем, посылка команд потоку, который спит в alertable состоянии. Ну а сколько времени он будет выполнять — сие от меня не зависит.

Но это как-бы не совсем то, о чём писал автор темы. Автор хочет, чтобы все запросы одного клиента (в широком смысле ) шли в указанный им поток А у Вас привязка идёт на уровне запроса, и это, кстати, очень хорошо разруливается портом завершения. Вообще советую обратить на него внимание, если интересуетесь темой. Прирост производительности по сравнению с другими способами просто поразительный.

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

Здравствуйте, <Аноним>, Вы писали:

А>Да и, честно говоря, не особенно улавливаю, как предложенный автором темы способ может снизить требования к синхронизации. Как правило. в каждый конкретный момент времени и без того обрабатывается один запрос от конкретного клиента. То есть от одного клиента приходит один запрос и пока он не обработан, других запросов от этого клиента не посткпает. Либо, что реже, от клиента могут поступить сразу несколько запросов, но тогда эти запросы никак между собой не связаны. Как-то не улавливаю, где тут выигрыш в синхронизации от использования схемы "все запросы одного клиента в одном потоке". Впрочем, возможно просто сказывается привычка мыслить "параллельно"

Вы исходите из предположения, что клиенты независимы. Это не всегда так. Не все сервера — это http сервера

Здравствуйте, jedi, Вы писали:

J>Здравствуйте, jedi, Вы писали:

А>>>По сути то, что Вы описываете, и есть функции порта, а Вы пытаетесь взять их на себя, но при этом обладете гораздо меньшими возможностями, чем порт. Возникает вопрос — зачем тогда порт? С тем-же успехом можно обойтись без него, вызывая в потоке WaitForMultipleObjects, это даже даст больше возможностей по управлению процессом.

J>>Ничего я не пытаюсь брать на себя. Порт — всего лишь способ асинхронного ввода-вывода. То что он берет на себя обязанности лоад-балансера когда потоков больше одного — хорошо. Но оно мне не надо.

Пытаетесь — пытаетесь В такой схеме WaitForMultipleObjects даст куда большую управляемость, порт просто не нужен.

J>И еще. То что Вы рассказывает (да и сама идея тред пула) хорошо работает для серверов где клиенты независимы.
J>Теперь представьте себя что-то типа игрового сервера, где все взаимодействуют со всем. Все эти выгоды виндового тред пула мгновенно испарятся от офигительной тучи блокировок.
J>Ну и, я вас уверею, в более-менее нетривиальном сервере с fine-grained locks будет жить зоопарк багов синхронизации (видел своими глазами).

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

Впрочем, коль Вам тема стала не интересна, то и продолжать нет смысла, мне она тем более ни к чему

Здравствуйте, <Аноним>, Вы писали:

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

Еще раз. Поток один на всех. Зачем синхронизация?

А>Впрочем, коль Вам тема стала не интересна, то и продолжать нет смысла, мне она тем более ни к чему

Мне тема интересна. Но Ваш пойнт я понял — ничего делать не надо, все и так работает . Я вполне четко указал где это, мягко говоря, не так. Вы проигнорировали. О чем говорить-то?

Здравствуйте, jedi, Вы писали:

J>Здравствуйте, <Аноним>, Вы писали:

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

J>Еще раз. Поток один на всех. Зачем синхронизация?

Действительно, незачем. Но тогда и всё остальное ни к чему. Зачем N портов, если поток один на всех? Вот только с масштабируемостью в такой схеме совсем худо. А если потоков всё-таки больше, чем один, то обязательно окажется, что два желающих взаимодействовать клиента "сидят" на разных потоках.

А>>Впрочем, коль Вам тема стала не интересна, то и продолжать нет смысла, мне она тем более ни к чему

J>Мне тема интересна. Но Ваш пойнт я понял — ничего делать не надо, все и так работает . Я вполне четко указал где это, мягко говоря, не так. Вы проигнорировали. О чем говорить-то?

Честно говоря, я не очень понимаю, из чего Вы вывели, будто я сказал "ничего делать не надо, все и так работает". Ещё меньше понимаю, где Вы "четко указал где это, мягко говоря, не так" Но говорить, судя по всему, действительно больше не о чем.

Желаю удачи.