Возник следующий вопрос.
Как должна распределяться память в хипе в случае многопоточной системы.

Логично, что у каждого потока должен быть собственный хип, с которым он и должен работать, так сделано в СПФ, но к примеру в Win32Forth используется глобальный хип, и любой поток получает память в нем. Есть и другие решения, например SwiftForth использует механизм VirtualAlloc, не привязанный к какому либо хипу.

В стандарте я не нашел (может пропустил) на этот счет никаких указаний.

Проблема возникает в случае обработки callback вызовов, потому что в случае СПФ использовать хип можно только на время одиночного колбэк вызова, то есть по выходу из callback процедуры хип удаляется.

Это логично. Но логичны и другие решения - тут уж как потребует программист.

И правильно.

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

Проблема в том, что не подходит такое общее решение.
Любая динамическая структура данных оказывается недоступной внутри callback, а это не приятно, так как надо следить за тем, какой код используется для таких вызвовов. В случае, когда у каждого потока индивидуальный ХИП просто невозможно работать стандартными средствами (ALLOCATE FREE) с динамическими структурами данных "подписанного" на асинхронное событие потока.
(Кстати, это проблема винды, в линуксе ее нет, в силу другого вида многозадачности).


не знаю на сколько это правильно. Это "узкое место" из-за которого код будет не переносим между системами.


собственно выше я ответил на этот вопрос. Проблема в том, что нельзя использовать произвольный существующий код, если он работает с хипом.

Вариант 1 - обертка. Вариант 2 - подойти к проблеме с той стороны, что если уж проблема есть, значит, она откуда-то взялась. И можно сначала посмотреть, откуда именно, и не стоит ли ее аккуратно обойти. Может быть, просто не "желать странного"?

не совсем понятно как.


вот в голову приходят следующие решения:

1) ограничить используемые средства в колбэк вызове
2) в "подписавшемся потоке" создать аналог message-loop и копировать в него данные (но тут могут возникнуть неприятности, например всвязи с рекурсивными колбэк вызовами).
3) сделать хип глобальным для всех потоков процесса и мириться с возможными утечками памяти, отдельно заботиться об освобождении памяти при завершении потока. То есть, ALLOCATE будет выделять память из любого потока в одном месте.
???

mOleg
А почему нельзя отдельный набор слов для работы с хипом
потока иметь. Тем более стандарт не указывает где память выделять.
Как основной механизм - ипользование хипа процесса
(соответствено удалять вручную)
Для локальных данных потока использовать другие слова работающие так как сейчас работает
ALLOCATE .
Да и данные обратываемые потоком не всегда должны быть локальными.
Может они будут использоваться в других потоках, тогда хип процесса вне конкуренции.


Кстати в однопоточном приложении используется хип основного потока
и его (поток) удалять нельзя ,так что память всё равно в ручную чистить надо


ну и зачем такие сложности.

mOleg посмотри почту еще примерчик на эту тему

да можно. Собственно проблема лишь в том, как это назвать я имею ввиду набор имен на замену ALLOCATE и FREE.


тем более, что в форке стандарт послан подальше как тормозящий развитие.


тут возникает вопрос, а нужен ли вообще хип потока?
Хипов может быть много, зачем фиксировать тогда за потоком один хип, тем более, что не удобно им пользваться.

О вопрос задан правильно т. е . пол ответа уже есть. Можно и совсем без него.
так как это сделано в виндовс создает больше проблем чем пользы.
По идее нужно было бы кроме закрытия доступа к изменению
размеров блока в хипе потока закрыть запись и чтение в него из других потоков.
Тогда был бы какойто смысл в хипе потока ( типа локальных переменных ).
Но это видимо потребует большой траты ресурсов.
Так что получилось не то ни се, и неудобств много, и пользы мало.

Есть одно но, вопросы совместимости
Или уже нет?

Вообще постановка вопроса немного неясна. Зачем закреплять хип за потоками? Какая цель преследуется по сравнению с ALLOCATE/FREE?

дело в том, что в рамках одного процесса в СПФ для каждого потока создается свой хип.
И ALLOCATE выделяет память для каждого потока в другом хипе. Именно об этом речь, так как с одной стороны такой подход логичен, а с другой неудобен.

ну, польза есть в том, что в случае утечек памяти, она (память) закончится позже, если, конечно будут переодически потоки завершаться.
А вообще виндошная многопоточность мне очень не симпатична.