tthread, не получается запустить больше ~120 нитей

[yser]

день добрый.

уже несколько дней в ступоре - может кто подскажет, почему fpc не дает запустить больше 120 нитей, а тоже приложение скомпилированное дельфой без проблем за 700 нитей уходит?

вот пример:

[Sergei I. Gorelkin]

Разный размер стека по умолчанию. Дельфи работает только в винде, которая автоматически расширяет стек по необходимости, поэтому в нем дается минимально возможный размер в 4кБайт. Другие ОС не умеют расширять стек, поэтому в FPC по умолчанию выделяется 4 МБайт стека на поток.

Умолчания можно изменить под собственные требования - размер стека передается вторым параметром в конструктор TThread.

[yser]

Разный размер стека по умолчанию. Дельфи работает только в винде, которая автоматически расширяет стек по необходимости, поэтому в нем дается минимально возможный размер в 4кБайт. Другие ОС не умеют расширять стек, поэтому в FPC по умолчанию выделяется 4 МБайт стека на поток.

Умолчания можно изменить под собственные требования - размер стека передается вторым параметром в конструктор TThread.

пробовал задавать разные размеры стека, на кол-во запускаемых нитей не влияет.
в приатаченном примере стек задан = 0 (вроде как размер как и основного процесса)

[FeodoR]

ИМХО, виндовая реализация. В Linux спокойно уходит за 300 нитей. Но время переключения между ними, если они все работают воистину демоническое.

[Bupyc]

Я когда то писал реализацию TCP сервера. В ней на каждое подключение создавалась своя собственная нить. Когда количество подключений выросло, то стали происходить непонятные зависания. В итоге я выяснил, что висла функция API CreateThread после того, как количество потоков перешагивало за сотню (ОС Win2k). Переписал сервер на работу с асинхронными API (WSAAsyncSelect и т.д.) и проблема пропала.

Может я, конечно, не прав, но у меня сложилось такое мнение, что если программе требуется создавать значительное кол-во нитей, то, возможно, надо пересмотреть её алгоритм. Не могу себе представить задачу, реализация которой требовала бы создание нескольких сотен нитей.

[yser]

Я когда то писал реализацию TCP сервера. В ней на каждое подключение создавалась своя собственная нить. Когда количество подключений выросло, то стали происходить непонятные зависания. В итоге я выяснил, что висла функция API CreateThread после того, как количество потоков перешагивало за сотню (ОС Win2k). Переписал сервер на работу с асинхронными API (WSAAsyncSelect и т.д.) и проблема пропала.

Может я, конечно, не прав, но у меня сложилось такое мнение, что если программе требуется создавать значительное кол-во нитей, то, возможно, надо пересмотреть её алгоритм. Не могу себе представить задачу, реализация которой требовала бы создание нескольких сотен нитей.

вот как раз tcp сервер, каждое подключение - нить, команды полученные из подключений также выполняются в отдельных нитях к томуже от одного подкючения может одновременно обрабатываться N-команд ... проблем с созданием нитей не было, нити создаются 1 раз после выполнения задачи не удаляются а засыпают и используются повторно для разных задач.
сервер скомпилированный на дельфе работает а вот скомпилировав на fpc немогу более 120 подключений сделать ....

спасибо за наводку на WSAAsyncSelect, попробую переписать на нем.

[Bupyc]

Не за что. Если нужно, могу скелет сервера накидать. Там всё достаточно просто.

[yser]

Не за что. Если нужно, могу скелет сервера накидать. Там всё достаточно просто.

буду очень признателен, надеюсь поможет быстрее разобраться с асинхронными api

[FeodoR]

Да простят меня все...

Не вижу тут более чем n+2 нитей, где n - число физических сетевых интерфейсов.

В случае одного. Интерфейс один. Один. Значит и выгребать его должен один, отдельно взятый для этого поток (нить). Второй уровень - обработчик того, что пришло из линии. Третий уровень - взаимодействие с пользователем, если таковой имеется.

Я бы сделал и без api, потому как api = привязка к конкретной ОС. Можно, в принципе, реализовать всё на уровне языка. Время выполнения/работы особо пострадать не должно.

Добавлено спустя 4 минуты 30 секунд:
Архитектура PC (x86, amd64), ИМХО, не предполагает работу с большим количеством нитей/пользователей/процессов. Это - PC, то есть персональный компьютер. А обработка огромного (для больших серверов) количества запросов - дань мегагерцам и высокоскоростным интерфейсам. Соответственно, надо задачу по обработке пристраивать к архитектуре машины. То есть стремиться минимизировать количество нитей/потоков. Либо стараться увязать их количество к количеству ядер в машине...

Повторюсь, моё ИМХО.

[Bupyc]

Интерфейс один. Один. Значит и выгребать его должен один, отдельно взятый для этого поток (нить). Второй уровень - обработчик того, что пришло из линии. Третий уровень - взаимодействие с пользователем, если таковой имеется.

Как это говорится, +1

Я бы сделал и без api, потому как api = привязка к конкретной ОС. Можно, в принципе, реализовать всё на уровне языка. Время выполнения/работы особо пострадать не должно.

Это у меня пережитки прошлого Лет 10-12 назад я начинал писать сетевые приложения и делал их на уровне АПИ. Сейчас у меня есть две реализации TCP сервера, одну из которых я использую в Windows (однопоточную), а другую (многопоточную) в Linux и WinCE.

[z.g]

Архитектура PC (x86, amd64), ИМХО, не предполагает работу с большим количеством нитей/пользователей/процессов.

тот же пример на дельфи создает легко 1000 нитей.

[FeodoR]

А как работает переключение между этими 1000 нитями, если их них хотя бы 20% активно? Мне кажется, что тормоза будут неимоверные и будет нестабильность в выдаче результатов работы тех самых потоков.

[yser]

А как работает переключение между этими 1000 нитями, если их них хотя бы 20% активно? Мне кажется, что тормоза будут неимоверные и будет нестабильность в выдаче результатов работы тех самых потоков.

в текущей момент работает среднее звено скомпилированное на дельфе, в среднем 40-50 человек постоянно подключены и работают, в пике было около 180 нитей (подключения + команд от пользователей) ... среднее звено работает уже больше 8 месяцев без перезагрузки.
перед тем как пустить в работу достаочно сильно нагружал тестами - среднее звено летало изумительно, самым слабым звено был sql сервер.

а вот решив перевести сервер на fpc - столкнулся стем что, не могу более 120 нитей создать

[alaken]

Разный размер стека по умолчанию. Дельфи работает только в винде, которая автоматически расширяет стек по необходимости, поэтому в нем дается минимально возможный размер в 4кБайт. Другие ОС не умеют расширять стек, поэтому в FPC по умолчанию выделяется 4 МБайт стека на поток.

Умолчания можно изменить под собственные требования - размер стека передается вторым параметром в конструктор TThread.

пробовал задавать разные размеры стека, на кол-во запускаемых нитей не влияет.
в приатаченном примере стек задан = 0 (вроде как размер как и основного процесса)

пробовал выставить увеличенное значение, памяти заняло все свободное, но ограничение в 120 нитей так и осталось.
интересная проблема, кто нибудь может объяснить почему именно такое ограничение?

[FeodoR]

Организация диспетчера потоков в Win32 средствами fpc. В *nix этого ограничения нет.

Но, ИМХО, такое количество нитей - намёк на переписывание алгоритмов.