если к ним полезет другой поток, то ничего хорошего не будет.
Верно, но выделение памяти под автоматическую переменную все равно потокобезопасно — оно происходит до того, как начинается время жизни переменной. Если другой поток пытается обратиться к переменной раньше, вы уже ходите по очень тонкому льду и это не связано с потокобезопасностью.
способ аллокации я предлагаю менять только для одного потока.
Как только вы пытаетесь сделать то же самое в еще одном потоке (а это вполне нормальное стремление), потокобезопасность становится актуальной.
В любом случае смысл затеи с выделенным распределителем в том, что вы экономите на освобождении памяти и фрагментации памяти. Для того, чтобы иметь возможность разрушить распределитель целиком, вам нужна уверенность, что к моменту разрушения распределителя нигде вне его не осталось указателей внутрь этого распределителя. Это не так просто, как может показаться на первый взгляд. В общем, идея работоспособная, но отнюдь не пуленепробиваемая и требующая большой дисциплины.
Да, это тоже путь. Например, можно использовать блочный распределитель памяти.
Правда есть одно «но». Куча в Visual C++ runtime потокобезопасная (и это одна из причин, почему она такая относительно небыстрая), в случае своего распределителя памяти о потокобезопасности придется хотя бы просто подумать.
Во-первых, нужно еще обстоятельно проверить, что с -Wframe-larger-than gcc вычисляет расход стека верно. Например, в Visual C++ есть /analyze:stacksize, который в общем работает, но во многих случаях вычисляет расход неверно. Может быть, в gcc это отлажено лучше и аналогичных проблем нет.
Во-вторых, не всегда же большой расход от того, что объявили массив большого размера на стеке явно. Мог быть большой массив в качестве поля класса, а временный объект этого класса мог быть создан автоматически при вызове функции.
В общем, действительно нужно по возможности пользоваться статическим анализом компилятора и проверять на тестовых пакетах, хватает ли стека уменьшенного размера.
Верно, но выделение памяти под автоматическую переменную все равно потокобезопасно — оно происходит до того, как начинается время жизни переменной. Если другой поток пытается обратиться к переменной раньше, вы уже ходите по очень тонкому льду и это не связано с потокобезопасностью.
Как только вы пытаетесь сделать то же самое в еще одном потоке (а это вполне нормальное стремление), потокобезопасность становится актуальной.
В любом случае смысл затеи с выделенным распределителем в том, что вы экономите на освобождении памяти и фрагментации памяти. Для того, чтобы иметь возможность разрушить распределитель целиком, вам нужна уверенность, что к моменту разрушения распределителя нигде вне его не осталось указателей внутрь этого распределителя. Это не так просто, как может показаться на первый взгляд. В общем, идея работоспособная, но отнюдь не пуленепробиваемая и требующая большой дисциплины.
Правда есть одно «но». Куча в Visual C++ runtime потокобезопасная (и это одна из причин, почему она такая относительно небыстрая), в случае своего распределителя памяти о потокобезопасности придется хотя бы просто подумать.
В том и дело, что это считается оптимизацией в смысле «сделаем как-нибудь, а потом оптимизируем», в то время как стек является дефицитным ресурсом.
Будет зависеть от компилятора, это надо проверять. На Visual C++ 10 так сразу не сломалось.
Расскажите, пожалуйста, как заставить компилятор использовать выделенный в куче блок памяти для локальных и временных переменных?
Во-первых, нужно еще обстоятельно проверить, что с -Wframe-larger-than gcc вычисляет расход стека верно. Например, в Visual C++ есть /analyze:stacksize, который в общем работает, но во многих случаях вычисляет расход неверно. Может быть, в gcc это отлажено лучше и аналогичных проблем нет.
Во-вторых, не всегда же большой расход от того, что объявили массив большого размера на стеке явно. Мог быть большой массив в качестве поля класса, а временный объект этого класса мог быть создан автоматически при вызове функции.
В общем, действительно нужно по возможности пользоваться статическим анализом компилятора и проверять на тестовых пакетах, хватает ли стека уменьшенного размера.