Здравствуйте, Sinix, Вы писали:
S>Если не лень — проверьте под lin, на скольки потоках загнётся?
Если 5000 не убирать, то всё доходит до порядка 20000 потоков. Потом выполняются decrement'ы и оно снова начинается.
Если поставить sleep(50000), то у меня дошло до 30000, потом начало свопиться (на виртуалке около 4Гб). Нативная версия дошла до 32700.
#include <unistd.h>
#include <stdio.h>
#include <vector>
#include <boost/thread.hpp>
using namespace std;
int main()
{
std::vector<boost::thread> all;
for(int n = 0; n <1000000; ++n)
{
boost::thread::attributes attrs;
attrs.set_stack_size(8192);
boost::thread th(attrs, []() {sleep(50000);});
all.push_back(std::move(th));
if (n % 100 == 0)
printf("%d\n", n);
}
};
Sapienti sat!
Re[20]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Вот видишь, ты сам все понимаешь. А еще реальные сервера могут скрываться за каким нибудь сервисом типа акамая. А еще 100500 сайтиков на ПХП, крутящихся на одном сервере, статистику в сайтах тоже соответственную делают.
Работаю в конторе, которая занимается ПО для сайтиков.
Тесно сотрудничаем с МС. Процент реальных сайтов на винде не превышает 10%.
Могу поделится такой инфой — МС приплачивает крупным хостерам, чтобы парковали домены на винде.
Отсюда рост количества сайтов на винде у всяких netcraft. На самом деле тенденция совсем иная — винда упорно теряет свои позиции...
Re[38]: Зачем Майкрософту рубить сук, на котором он сидит?
Вообще-то Tasks и обеспечивают абстрацию как в отношении процессора, так и ОСи. И они входят во многие portable subset. Это позволяет выполнять их независимо от того, как они реализованы на desktop или мобильном устройстве. Но когда внутренняя реализация критична, можно использовать платформенно-зависимые потоки, в этом случае они будут разными для разных ОСей.
Re[39]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Ilya81, Вы писали:
I>Вообще-то Tasks и обеспечивают абстрацию как в отношении процессора, так и ОСи. И они входят во многие portable subset. Это позволяет выполнять их независимо от того, как они реализованы на desktop или мобильном устройстве. Но когда внутренняя реализация критична, можно использовать платформенно-зависимые потоки, в этом случае они будут разными для разных ОСей.
См пост выше:
таски — это не потоки, это абстракция уровнем выше. За Task может скрываться классический поток, шедулер TPL, шедулер ms sql, iocp-порт или вообще балансер для кластера, как в orleans.
Вы точно мне отвечали?
Re[41]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Nikе, Вы писали:
НС>>Ага, если обеспечить отдельную поддержку зеленых потоков.
N>А зачем они нужны в наше время?
Как и раньше — ресурсы экономить. Для задач, где мало вычислений и много работы с сетью, IO и тд, незачем плодить нативные потоки.
Потому серверы WoT или Eve Online написаны на пейтоне или стеклесс пейтоне, шоб сильнее было. Зеленая нитка на тормозном пейтоне переключается на другую быстрее чем мега-нативный высокосиплюсный код с потока на поток.
Re[42]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Ikemefula, Вы писали:
I>Как и раньше — ресурсы экономить. Для задач, где мало вычислений и много работы с сетью, IO и тд, незачем плодить нативные потоки.
С такими задачами прекрасно справляются и IOCP.
Re[43]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Как и раньше — ресурсы экономить. Для задач, где мало вычислений и много работы с сетью, IO и тд, незачем плодить нативные потоки.
НС>С такими задачами прекрасно справляются и IOCP.
В своём уме IOCP руками никто не прогает, только пару маньяков, навроде тех что пишут nginx и подобные вещи. Зеленые потоки искаропки хорошо поддерживают асинхронную работу с IO.
Re[44]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Ikemefula, Вы писали:
I>В своём уме IOCP руками никто не прогает
Что значит руками? Таски поверх IOCP это все еще руками или уже нет? А FileStream.BeginRead?
I>Зеленые потоки искаропки хорошо поддерживают асинхронную работу с IO.
Для использования IOCP зеленые потоки не нужны.
Re[45]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>В своём уме IOCP руками никто не прогает
НС>Что значит руками? Таски поверх IOCP это все еще руками или уже нет? А FileStream.BeginRead?
Таски используют iocp так же как и зеленые потоки, ничуть не лучше и не хуже. А вот извраты FileStream.BeginRead в своём уме никто не использует, кроме как для мелочевки, которую без разницы на чем писать.
I>>Зеленые потоки искаропки хорошо поддерживают асинхронную работу с IO.
НС>Для использования IOCP зеленые потоки не нужны.
Не нужны это значит, что зеленые потоки для IOCP не являются обязательными, если руссуждать в дали от экономической целесообразности.
Без зеленых потоков получится моделька навроде той что в nginx. Разработчиков такого уровня в каждом регионе по пару штук.
Re[46]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Ikemefula, Вы писали:
I>Таски используют iocp
Сами таски не используют, используют их конкретные IO bound методы.
I>А вот извраты FileStream.BeginRead в своём уме никто не использует
А что там такого извратного?
НС>>Для использования IOCP зеленые потоки не нужны. I>Не нужны это значит, что зеленые потоки для IOCP не являются обязательными
Нет, это значит что не нужны. Совсем.
I>Без зеленых потоков получится моделька навроде той что в nginx.
Моделька получится та, которая нужна. Например таски, которые работают с IOCP без всяких зеленых потоков.
Re[47]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Сами таски не используют, используют их конкретные IO bound методы.
I>>А вот извраты FileStream.BeginRead в своём уме никто не использует
НС>А что там такого извратного?
В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности, если у тебя одна переменная и методы навроде BeginRead, BeginWrite и тд.
Внезапно, даже в однопоточной модели возникают гонки в силу кооперативной многозадачности. В зеленых потоках эту проблему проще контролировать.
I>>Не нужны это значит, что зеленые потоки для IOCP не являются обязательными
НС>Нет, это значит что не нужны. Совсем.
Я боюсь даже спрашивать, как ты понимаешь слово "нужен". Вот С# не нужен, потому что есть N других языков программирования. Прикинь ?
I>>Без зеленых потоков получится моделька навроде той что в nginx.
НС>Моделька получится та, которая нужна. Например таски, которые работают с IOCP без всяких зеленых потоков.
Таски работают с IOCP ровно так же, как и зелёные потоки, один к одному, только зеленые потоки обычно проще тасков, там не надо поддержвать сто тыщ пиццот разных контекстов и потоковых моделей.
Есть разве что такое отличие — Микрософт всунула в таски все что только смогла придумать. Похоже, когда вижла без единого плагина виснет на часы при обращении к TFS, тамошние таски усилено чтото делают. Вероятно, разработчики в МС сами не понимают, как работают таски. А когда вижла зависает и сообщает что чем то занята, пудозреваю, это те же таски.
Re[48]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Ikemefula, Вы писали:
I>В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности
Сумма последовательности это CPU bound задача, при чем тут IOCP?
I>>>Не нужны это значит, что зеленые потоки для IOCP не являются обязательными НС>>Нет, это значит что не нужны. Совсем. I>Я боюсь даже спрашивать, как ты понимаешь слово "нужен".
То и понимаю. Зеленые потоки IOCP совершенно ортогональны.
НС>>Моделька получится та, которая нужна. Например таски, которые работают с IOCP без всяких зеленых потоков. I>Таски работают с IOCP ровно так же, как и зелёные потоки, один к одному
Ага, а еще они работают с IOCP так же, как куча другого кода. Просто по тому что есть один единственный способ с ними работать
Re[48]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Ikemefula, Вы писали:
I>>А вот извраты FileStream.BeginRead в своём уме никто не использует I>В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности, если у тебя одна переменная и методы навроде BeginRead, BeginWrite и тд. I>Внезапно, даже в однопоточной модели возникают гонки в силу кооперативной многозадачности. В зеленых потоках эту проблему проще контролировать.
Есть такое подозрение, что таски ты вообще не использовал
TaskFactory.FromAsync(), дальше всё то же, что и с любыми другими тасками.
I>Таски работают с IOCP ровно так же, как и зелёные потоки, один к одному, только зеленые потоки обычно проще тасков, там не надо поддержвать сто тыщ пиццот разных контекстов и потоковых моделей. I>Есть разве что такое отличие — Микрософт всунула в таски все что только смогла придумать. Похоже, когда вижла без единого плагина виснет на часы при обращении к TFS, тамошние таски усилено чтото делают. Вероятно, разработчики в МС сами не понимают, как работают таски. А когда вижла зависает и сообщает что чем то занята, пудозреваю, это те же таски.
А вот теперь — не подозрение, а твёрдая уверенность
Я бы всё-таки подучил матчасть перед спором. Потому что буквально все утверждения выше: "ExecutionContext не нужен", "таски нельзя отладить", "таски === 100500 потоковых моделей" и т.д. к реальности никак не относятся.
Re[49]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности
НС>Сумма последовательности это CPU bound задача, при чем тут IOCP?
Для демонстрации особенностей кооперативной многозадачности. Представь, что есть один ресурс и много асинхронных писателей. Поток, который физический, ровно один. Валяей.
НС>Ага, а еще они работают с IOCP так же, как куча другого кода. Просто по тому что есть один единственный способ с ними работать
И внезапно оказывается, что в зеленых потоках код получается наиболее простым из всех вариантов реализации. Более того, он вообще мало отличим от синхронного.
Re[50]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Sinix, Вы писали:
S>Есть такое подозрение, что таски ты вообще не использовал S>TaskFactory.FromAsync(), дальше всё то же, что и с любыми другими тасками.
Тебе нужно всего ничего — доказать, что в кооперативной многозадачности гонки невозможны.
I>>Таски работают с IOCP ровно так же, как и зелёные потоки, один к одному, только зеленые потоки обычно проще тасков, там не надо поддержвать сто тыщ пиццот разных контекстов и потоковых моделей. I>>Есть разве что такое отличие — Микрософт всунула в таски все что только смогла придумать. Похоже, когда вижла без единого плагина виснет на часы при обращении к TFS, тамошние таски усилено чтото делают. Вероятно, разработчики в МС сами не понимают, как работают таски. А когда вижла зависает и сообщает что чем то занята, пудозреваю, это те же таски.
S>А вот теперь — не подозрение, а твёрдая уверенность
Я правильно понимаю, проблемы с тасками у их создателя показывают что проблемы с тасками у меня ? Браво !
S>Я бы всё-таки подучил матчасть перед спором. Потому что буквально все утверждения выше: "ExecutionContext не нужен", "таски нельзя отладить", "таски === 100500 потоковых моделей" и т.д. к реальности никак не относятся.
Ты немного додумал за меня, процентов на 90. Вместо "ExecutionContext не нужен" было " не надо поддержвать сто тыщ пиццот разных контекстов и потоковых моделей"
Таски нельзя отладить — речь была про APM-модель. Будет гаранировано АДЪ. Собственно, с тасками у микрософта пока что не сильно лучше.
Я показал задачу — один поток, один ресурс, несколько асинхронных читателей-писателей сделаных чз BeginXXX и EndXXX и задача, можно самую примитивную — сумму элементов какой нибудь последовательсности.
Вобщем, постарайся ответить не до того, как решишь задачу, а после того.
P.S. задача и её решение есть в этом форуме, на джаваскрипте. Поиск не работает, так что помочь не могу.
Re[50]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Ikemefula, Вы писали:
S>>TaskFactory.FromAsync(), дальше всё то же, что и с любыми другими тасками. I>Тебе нужно всего ничего — доказать, что в кооперативной многозадачности гонки невозможны.
Внезапно...
Напомню контекст, твой прошлый пост:
А вот извраты FileStream.BeginRead в своём уме никто не использует
В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности, если у тебя одна переменная и методы навроде BeginRead, BeginWrite и тд.
Внезапно, даже в однопоточной модели возникают гонки в силу кооперативной многозадачности. В зеленых потоках эту проблему проще контролировать.
Можешь объяснить, при чём тут вообще кооперативная многозадачность и какой магией зелёные потоки будут отличаться от тасков?
S>>А вот теперь — не подозрение, а твёрдая уверенность I>Я правильно понимаю, проблемы с тасками у их создателя показывают что проблемы с тасками у меня ? Браво !
Нет, пойнт в другом: ты вбрасывашь цепочку вообще никак не связанных утверждений аля
Микрософт всунула в таски все что только смогла придумать
разработчики в МС сами не понимают, как работают таски
когда вижла зависает и сообщает что чем то занята, пудозреваю, это те же таски
причём все, такое впечатление, только что из пальца высосан. И делаешь вывод: у тасков есть проблемы.
Сорри, но ни один человек, понимающий, как устроены таски, что с их помощью можно делать, что нельзя, такой бред не напишет. И тем более не будет доказывать сначала, что таски — это зелёные потоки
.
Какому из твоих утверждений верить?
I>Ты немного додумал за меня, процентов на 90. Вместо "ExecutionContext не нужен" было " не надо поддержвать сто тыщ пиццот разных контекстов и потоковых моделей"
В тасках ровно одна модель. За неё прячется практически что угодно — от обычных потоков до акторов и динамического раскидывания вызовов по кластеру. Только не надо начинать за "это всё не нужно"
I>Таски нельзя отладить — речь была про APM-модель. Будет гаранировано АДЪ. Собственно, с тасками у микрософта пока что не сильно лучше.
Ты 100% не использовал Parallel Stacks Window. Т.е. с тасками по сути не работал, о чём и было сказано выше. Про отладку в VS 1013 с поддержкой awiat и прочих плюшек даже начинать не буду.
I>Я показал задачу — один поток, один ресурс, несколько асинхронных читателей-писателей сделаных чз BeginXXX и EndXXX и задача, можно самую примитивную — сумму элементов какой нибудь последовательсности.
Observable.FromAsync(...).Sum();
или
var t = await source.Select(s=>Task.FromAsync(s.BeginXXX, ...)).WhenAll()
t.Sum(t=>t.Result);
+ возможно plinq (c ходу не вспомню, можно ли там прикрутить APM).
I>P.S. задача и её решение есть в этом форуме, на джаваскрипте. Поиск не работает, так что помочь не могу.
Что, проще вышеперечисленного?
Re[51]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Для демонстрации особенностей кооперативной многозадачности.
НС>IOCP и BeginRead это не кооперативная многозадачность.
Спасибо, капитан. Зато асинхронщина в одном потоке, которая возникает из за IOCP и BeginRead, аккурат кооперативная многозадачность и есть.
I>>И внезапно оказывается, что в зеленых потоках код получается наиболее простым
НС>Нет, не оказывается.
Мой вариант задачи и её решения есть в этом форуме, а твоего нет и скорее всего никогда не будет. Так шта...
I>> из всех вариантов реализации. Более того, он вообще мало отличим от синхронного.
НС>Ты путаешь зеленые потоки и встраивание continuation monad в компиляторы.
А где я говорил про монады и компиляторы ?
Re[52]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Ikemefula, Вы писали:
НС>>IOCP и BeginRead это не кооперативная многозадачность. I>Спасибо, капитан. Зато асинхронщина в одном потоке
"У рыб нет меха, поэтому блох у нее нет. А вот если бы мех был ...".
I>, которая возникает из за IOCP и BeginRead, аккурат кооперативная многозадачность и есть.
Не знаю что у тебя там возникает, но таски прекрасно справляются без кооперативной многозадачности.
I>>>И внезапно оказывается, что в зеленых потоках код получается наиболее простым НС>>Нет, не оказывается. I>Мой вариант задачи и её решения есть в этом форуме, а твоего нет и скорее всего никогда не будет. Так шта...
Ссылки давай, я за тобой не слежу что и где ты писал.
Re[51]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Sinix, Вы писали:
S>Напомню контекст, твой прошлый пост: S>
S>А вот извраты FileStream.BeginRead в своём уме никто не использует
S>В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности, если у тебя одна переменная и методы навроде BeginRead, BeginWrite и тд.
S>Внезапно, даже в однопоточной модели возникают гонки в силу кооперативной многозадачности. В зеленых потоках эту проблему проще контролировать.
S>Можешь объяснить, при чём тут вообще кооперативная многозадачность и какой магией зелёные потоки будут отличаться от тасков?
Если в одном потоке всякие IOCP, BeginXXX, EndXXX, то асинхронщина здесь и есть та самая кооперативная многозадачность.
S>Нет, пойнт в другом: ты вбрасывашь цепочку вообще никак не связанных утверждений аля S>
S>Микрософт всунула в таски все что только смогла придумать
S>разработчики в МС сами не понимают, как работают таски
S>когда вижла зависает и сообщает что чем то занята, пудозреваю, это те же таски
Связь вполне простая — всунули столько, что сами не смогли это осмыслить, пример — вижла.
S>Сорри, но ни один человек, понимающий, как устроены таски, что с их помощью можно делать, что нельзя, такой бред не напишет. И тем более не будет доказывать сначала, что таски — это зелёные потоки
Таски это плохая реализация зеленых потоков. Все смешали в кучу — и асинхронщину, и контексты и потоки, все до чего смогли дотянуться.
I>>Ты немного додумал за меня, процентов на 90. Вместо "ExecutionContext не нужен" было " не надо поддержвать сто тыщ пиццот разных контекстов и потоковых моделей" S>В тасках ровно одна модель. За неё прячется практически что угодно — от обычных потоков до акторов и динамического раскидывания вызовов по кластеру. Только не надо начинать за "это всё не нужно"
Там много больше, чем одна модель. Из того, что все все перечисленное по отдельности нужно, вовсе не значит, что мешанина из всего этого и есть то самое наилучшее решение.
I>>Таски нельзя отладить — речь была про APM-модель. Будет гаранировано АДЪ. Собственно, с тасками у микрософта пока что не сильно лучше. S>Ты 100% не использовал Parallel Stacks Window. Т.е. с тасками по сути не работал, о чём и было сказано выше. Про отладку в VS 1013 с поддержкой awiat и прочих плюшек даже начинать не буду.
Я await сам написал, когда этого в языке еще не было. Так шта..
I>>Я показал задачу — один поток, один ресурс, несколько асинхронных читателей-писателей сделаных чз BeginXXX и EndXXX и задача, можно самую примитивную — сумму элементов какой нибудь последовательсности. S>
S>
S>+ возможно plinq (c ходу не вспомню, можно ли там прикрутить APM).
Итого — кода у тебя нет. До свидания.
I>>P.S. задача и её решение есть в этом форуме, на джаваскрипте. Поиск не работает, так что помочь не могу. S>Что, проще вышеперечисленного?
Разумеется. Обычный код который выглядит как синхронный. В ём даже await не будет.
