Здравствуйте, Silent_Sasha, Вы писали:
S_S>Как расчитать размер стека для функции запускаемой в CreateThread S_S>Скажем функция unsigned f(int* arg){ int* a; a= arg; return a;} S_S>Спасибо.
А зачем?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, Silent_Sasha, Вы писали:
S_S>>Как расчитать размер стека для функции запускаемой в CreateThread S_S>>Скажем функция unsigned f(int* arg){ int* a; a= arg; return a;} S_S>>Спасибо. LVV>А зачем?
Что-бы задать оптимальный размер стека в CreateThread
Здравствуйте, Silent_Sasha, Вы писали:
S_S>Здравствуйте, LaptevVV, Вы писали:
LVV>>Здравствуйте, Silent_Sasha, Вы писали:
S_S>>>Как расчитать размер стека для функции запускаемой в CreateThread S_S>>>Скажем функция unsigned f(int* arg){ int* a; a= arg; return a;} S_S>>>Спасибо. LVV>>А зачем?
S_S>Что-бы задать оптимальный размер стека в CreateThread
сумма всех аргументов + локальных переменных + адрес возврата + указатель фрейма стека
Здравствуйте, Silent_Sasha, Вы писали:
S_S>>>Как расчитать размер стека для функции запускаемой в CreateThread S_S>>>Скажем функция unsigned f(int* arg){ int* a; a= arg; return a;} S_S>>>Спасибо. LVV>>А зачем?
S_S>Что-бы задать оптимальный размер стека в CreateThread
А по умолчанию он не ставится?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Silent_Sasha, Вы писали:
SS> Здравствуйте, LaptevVV, Вы писали: SS> LVV>> Здравствуйте, Silent_Sasha, Вы писали: SS> SS> S_S>>Как расчитать размер стека для функции запускаемой в CreateThread SS> S_S>>Скажем функция unsigned f(int* arg){ int* a; a= arg; return a;} SS> S_S>>Спасибо. LVV>> А зачем? SS> SS> Что-бы задать оптимальный размер стека в CreateThread
Глупости все это. Стек по умолчанию равен 1Мб, но это размер резервируемой, а не передаваемой памяти. Передается потоку одна страничка (4Кб), так что если он за эти 4Кб не выйдет, то и памяти не будет задействовано. Таким образом, стеку потока передается памяти согласно его максимальному пиковому значению. Сэкономить тут ничего нельзя, ибо как ничего эффективнее "just-in-time" (выделения по требованию) для ресурсов пока не придумали.
Вот если наоборот, известно, что поток будет активно использовать много стека, то можно задать ему большой размер стека, дабы сэкономить время на многочисленных VirtualAlloc. Но это уже извращение.
-- Всего хорошего!
-- Alex Alexandrov, e-mail: alexandrov_alex@fromru.com
Posted via RSDN NNTP Server 1.7 beta
It's kind of fun to do the impossible (Walt Disney)
Re[4]: Размер стека для потоковой функции
От:
Аноним
Дата:
10.09.03 15:54
Оценка:
Здравствуйте, alexandrov_alex, Вы писали:
[]
_>Глупости все это. Стек по умолчанию равен 1Мб, но это размер резервируемой, а не передаваемой памяти. Передается потоку одна страничка (4Кб), так что если он за эти 4Кб не выйдет, то и памяти не будет задействовано. Таким образом, стеку потока передается памяти согласно его максимальному пиковому значению. Сэкономить тут ничего нельзя, ибо как ничего эффективнее "just-in-time" (выделения по требованию) для ресурсов пока не придумали.
Не совсем так. Все же этот мегабайт резервируется в адресном пространстве, поэтому при очень большом количестве потоков (напр. если приложение -- это сервер, где каждый клиент обслуживается отдельным потоком) эта величина может стать ограничивающим фактором.
2 гб user адресного пространства поделить на 1 мб — получим 2000 тредов на один процесс. Пусть даже 1000 (исключим первые 64 кб guard pages + другие подобные + надо же тредам и динамической памяти немного). Думается, 1000 тредов на один процесс более чем достаточное количество для _общих_ нужд. Сервера, где требуется обслуживать большое количество клиентов одновременно и обеспечить при этом макс. производительность, пишутся на количестве потоков num_processors <= num_threads <= num_processors *2, используя для обслуживания клиентов порты ввода/вывода.
Это:
1. Позволяет экономить на переключениях контекста (тред все таки достаточно тяжелый объект)
2. Повышает общую производительность за счет полного использования многопроцессорных систем.
3. Уменьшает расход памяти (как kernel, так и user)
4. Прочее, что следует и не следует из первых 3-х
Так что оптимизировать надо не размер стека, выделяемый треду, а использование тредов.
_>>Глупости все это. Стек по умолчанию равен 1Мб, но это размер резервируемой, а не передаваемой памяти. Передается потоку одна страничка (4Кб), так что если он за эти 4Кб не выйдет, то и памяти не будет задействовано. Таким образом, стеку потока передается памяти согласно его максимальному пиковому значению. Сэкономить тут ничего нельзя, ибо как ничего эффективнее "just-in-time" (выделения по требованию) для ресурсов пока не придумали.
А>Не совсем так. Все же этот мегабайт резервируется в адресном пространстве, поэтому при очень большом количестве потоков (напр. если приложение -- это сервер, где каждый клиент обслуживается отдельным потоком) эта величина может стать ограничивающим фактором.
А>[]
Здравствуйте, Andrew S, Вы писали:
AS> 2 гб user адресного пространства поделить на 1 мб — получим 2000 тредов AS> на один процесс. Пусть даже 1000 (исключим первые 64 кб guard pages + AS> другие подобные + надо же тредам и динамической памяти немного). AS> Думается, 1000 тредов на один процесс более чем достаточное количество AS> для _общих_ нужд. Сервера, где требуется обслуживать большое количество AS> клиентов одновременно и обеспечить при этом макс. производительность, AS> пишутся на количестве потоков num_processors <= num_threads <= AS> num_processors *2, используя для обслуживания клиентов порты AS> ввода/вывода. Это: AS> 1. Позволяет экономить на переключениях контекста (тред все таки AS> достаточно тяжелый объект) 2. Повышает общую производительность за счет AS> полного использования многопроцессорных систем. 3. Уменьшает расход AS> памяти (как kernel, так и user) 4. Прочее, что следует и не следует из AS> первых 3-х AS> AS> Так что оптимизировать надо не размер стека, выделяемый треду, а AS> использование тредов. AS>
Полностью согласен. Даже добавлять ничего не буду.
-- Всего хорошего!
-- Alex Alexandrov, e-mail: alexandrov_alex@fromru.com
Posted via RSDN NNTP Server 1.7 beta
It's kind of fun to do the impossible (Walt Disney)
хъ
_>Глупости все это. Стек по умолчанию равен 1Мб, но это размер резервируемой, а не передаваемой памяти. Передается потоку одна страничка (4Кб),
На самом деле передаются две страницы. Читать Рихтера.
хъ
_>Вот если наоборот, известно, что поток будет активно использовать много стека, то можно задать ему большой размер стека, дабы сэкономить время на многочисленных VirtualAlloc. Но это уже извращение.
А вот задать больший размер стека (чем задано в PE) под ОС ниже XP не получиться. Размер стека в функции CreateThread задает размер передаваемой области.
Здравствуйте, Alexey Shirshov, Вы писали:
AS> На самом деле передаются две страницы. Читать Рихтера.
Верное замечание.
AS> А вот задать больший размер стека (чем задано в PE) под ОС ниже XP не AS> получиться. Размер стека в функции CreateThread задает размер AS> передаваемой области.
Это из документации или из опыта? Я ничего не нашел по этому поводу. Только обратное:
To increase the amount of stack space which is to be initially committed for a thread, specify the value in the dwStackSize parameter of the CreateThread function. This value is rounded to the nearest page and used to set the initial size of the committed memory. The call to CreateThread will fail if there is not enough memory to commit the number of bytes you request. If dwStackSize is smaller than the default reserve size, the new thread uses the default reserve size. If dwStackSize is larger than the default reserve size, the reserve size is rounded up to the nearest multiple of 1 MB.
-- Всего хорошего!
-- Alex Alexandrov, e-mail: alexandrov_alex@fromru.com
Posted via RSDN NNTP Server 1.7 beta
It's kind of fun to do the impossible (Walt Disney)
хъ
_>Это из документации или из опыта? Я ничего не нашел по этому поводу. Только обратное:
Где ж обратное.
_>
_>To increase the amount of stack space which is to be initially committed for a thread, specify the value in the dwStackSize parameter of the CreateThread function. This value is rounded to the nearest page and used to set the initial size of the committed memory. The call to CreateThread will fail if there is not enough memory to commit the number of bytes you request. If dwStackSize is smaller than the default reserve size, the new thread uses the default reserve size. If dwStackSize is larger than the default reserve size, the reserve size is rounded up to the nearest multiple of 1 MB.
commit значит передавать. Т.е. здесь и написано
Размер стека в функции CreateThread задает размер передаваемой области.
А вот флаг для XP
Windows XP: If the STACK_SIZE_PARAM_IS_A_RESERVATION flag is specified, the dwStackSize parameter specifies the initial reserve size of the stack. Otherwise, dwStackSize specifies the commit size.
Здравствуйте, Alexey Shirshov, Вы писали:
AS> Где ж обратное.
... Пропущено ...
AS> А вот флаг для XP AS>
AS> Windows XP: If the STACK_SIZE_PARAM_IS_A_RESERVATION flag is specified,
AS> the dwStackSize parameter specifies the initial reserve size of the
AS> stack. Otherwise, dwStackSize specifies the commit size.
AS> AS> []
А вот там и обратное. Про передаваемую память я и не говорил. Я говорил вот про это:
AS> А вот задать больший размер стека (чем задано в PE) под ОС ниже XP не получиться.
Это с чего?
-- Всего хорошего!
-- Alex Alexandrov, e-mail: alexandrov_alex@fromru.com
Posted via RSDN NNTP Server 1.7 beta
It's kind of fun to do the impossible (Walt Disney)
AS>> А вот задать больший размер стека (чем задано в PE) под ОС ниже XP не получиться.
_>Это с чего?
Ну потому что только с XP появился флаг STACK_SIZE_PARAM_IS_A_RESERVATION!
Без него приходится при линковке задавать размер стека по умолчанию (тот, который резервируется).
Здравствуйте, Alexey Shirshov, Вы писали:
AS> Ну потому что только с XP появился флаг AS> STACK_SIZE_PARAM_IS_A_RESERVATION! Без него приходится при линковке AS> задавать размер стека по умолчанию (тот, который резервируется).
Тогда так и говори: невозможно задать программно БОЛЬШОЕ резервируемое значение размера стека, не передав при этом стеку потока физической памяти.
-- Всего хорошего!
-- Alex Alexandrov, e-mail: alexandrov_alex@fromru.com
Posted via RSDN NNTP Server 1.7 beta
It's kind of fun to do the impossible (Walt Disney)
_>Полностью согласен. Даже добавлять ничего не буду.
для этого даже есть специальная кнопка Согласен
... << RSDN@Home 1.1 beta 2 >>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.