Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Пт мар 29, 2024 02:57

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 28 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Работа с памятью Форт-системы.
СообщениеДобавлено: Сб ноя 14, 2009 16:23 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
Автор: mOleg
Дата публикации: 14.11.2009

публикуется впервые

Работа с памятью Форт-систем

Введение
Традиционно в Форт-системах для работы с памятью системы используется механизм HERE ALLOT в различных вариациях. В простейшем случае в системе имеется всего одно адресное пространство, а память распределяется с помощью очень простого механизма. Создается указатель на конец используемой памяти, который обычно называется DP (data pointer):
VARIABLE DP ( --> addr ) \ указатель может быть обычной глобальной переменной

с самим указателем не работают напрямую, а используют следующие слова:
\ вернуть адрес первого неиспользованного байта(ячейки) в памяти системы
: HERE ( --> addr ) DP @ ;

\ зарезервировать (освободить) указанное количество адресуемых единиц (обычно байт) в памяти системы
: ALLOT ( # --> ) DP +! ;

\ резервировать место на HERE , сохранить значение n в выделенной области
: , ( n --> ) HERE CELL ALLOT ! ;

Все остальные слова для работы с памятью системы строятся по похожему сценарию. То есть, в случае добавления еще одного адресного пространства, к примеру, пользовательской области, будут использоваться: USER-DP USER-HERE USER-ALLOT и т.д. В случае необходимости сохранять не только ячейки, а к примеру, символьные значения, добавляется: C, ; для строк, добавляется S, и т.д.

Выравнивание данных в памяти системы производится с помощью слова ALIGNED и определенного через него:
\ выровнять указатель DP на значение, 
: ALIGN ( --> ) HERE DUP ALIGNED SWAP – ALLOT ;

причем, величина, на которую производится выравнивание, в системе обычно задается либо константой, либо VALUE переменной.
Указатель DP (или аналог) не обязательно хранит правильный адрес, он может хранить, к примеру, смещение от чего-либо. Это означает, что обращаться к DP напрямую нельзя: резервировать место можно только с помощью ALLOT , а получать действительный адрес с помощью HERE. При этом, наиболее правильной стратегией при работе с памятью является предварительное выделение места на HERE с последующим сохранением данных, то есть последовательность:
... HERE ! 

CELL ALLOT

не правильна по нескольким причинам:

1. в случае многопоточной системы несколько потоков могут попытаться сохранить данные в одно и то же место (впрочем, многопоточная компиляция – это отдельный разговор)
2. возможна ситуация, когда за HERE память вообще не адресуется, к примеру, если эта память выделяется в ХИПе.
3. память за HERE может использоваться для временного хранения данных (у некоторых фортеров есть ужасная привычка использовать указатель HERE для временного хранения данных, к примеру, слово WORD во многих системах копирует выкусываемое из входящего потока слово (лексему) в область за HERE (иногда с небольшим отступом)).

Предлагаемые изменения и дополнения
В добавление к существующим словам очень напрашивается добавить несколько дополнительных определений:
\ зарезервировать место в памяти, длиной в # минимально адресуемых единиц,
\ вернуть адрес начала выделенной области
: PLACE ( # --> addr ) HERE SWAP ALLOT ;

\ выровнять число base на указанное значение n
\ граница выравнивания произвольная.
\ выравнивание производится в большую сторону
: ROUND ( addr base --> addr ) TUCK 1 - + OVER / * ;

После чего, переопределить ALIGNED следующим образом:
\ округлить адрес к ближайшему большему значению, кратному ALIGN#
: ALIGNED ( addr --> a-addr ) ALIGN# ROUND ;

Впрочем, с выравниванием данных в памяти связано достаточно много моментов:
- для каждого отдельного адресного пространства величина выравнивания может сильно отличаться;
- для каждого вида данных выравнивание может требоваться на разные величины;
- в ряде случаев необходимо выравнивание с заполнением, к примеру, NOP-ами в случае выравнивания кода;
- в разных потоках для одного адресного пространства может требоваться разное выравнивание.

В связи с тем, что указатель данных DP может иметь различную природу (быть простой переменной, VALUE переменной, вектором, определением), было бы замечательно, чтобы слово HERE (и подобные ему слова) всегда возвращало действительные адреса!
К сожалению, в данный момент это не всегда так (в том же СПФ USER-HERE возвращает не действительный адрес, а смещение относительно начала пользовательской области).

Принадлежность кода и данных
Код и данные в Форт системе не существуют сами по себе. Каждый кусок кода и данных (обычно) связан с конкретным именем, и может быть вызван по имени. Исключением являются :NONAME определения, но не во всех Форт-системах они существуют, и далеко не всегда совсем не имеют поля имени. Вне зависимости от того, в каком адресном пространстве находится код, ссылка на него может быть получена только через поиск ассоциируемого с ним имени в одном из словарей системы. Создание нового определение начинается с создания заголовка с помощью слова HEADER (или подобного ему). HEADER создает заголовок слова и включает его в текущий словарь, сохраняет в поле ссылки адрес на текущее HERE , после чего можно создавать поле кода, если оно необходимо.

Многопоточная компиляция
Достаточно легко заметить, что работа с памятью обычно разбита на некие «сеансы» , которые начинаются созданием очередного определения и заканчиваются к моменту создания следующего за ним. А это значит, что в случае многопоточной компиляции можно выбрать две возможные стратегии:

A) собирать определение в отдельном участке памяти, уникальном для данного потока, и после завершения сборки переносить код в общее пространство;
Б) блокировать доступ к общему для потоков адресному пространству кода и данных на время сборки очередного определения (так сделано в форке).

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

Преимуществом варианта А является возможность одновременной компиляции в нескольких потоках, с редкими блокировками доступа к общему пространству памяти на время переноса кода, а так же возможность «легкого отката» в случае возникновения ошибки, так как собираемое слово еще не включено в общий словарь. Кроме того, в момент переноса кода определения на место напрашивается преобразование (оптимизация) кода. Однако реализация варианта А достаточно сложна.
Преимущество варианта Б в том, что для сборки нового определения не нужно выделять место где-то еще (определение собирается на месте), а так же нет нужды в переносе кода (правке адресных ссылок). Недостатком является невозможность одновременной компиляции: то есть пока один поток работает с общим хранилищем кода и данных другой должен ожидать освобождения ресурса. Зато вариант Б проще в реализации.

В любом случае необходимо использовать слово ;CREATE ( --> ) которое будет в зависимости от выбранного варианта либо переносить уже собранный код в общее хранилище, добавляя имя в текущий словарь (для варианта А), либо просто освобождать мьютекс, позволяя другому потоку начать сборку нового определения (если этого не сделать, то компилировать всегда будет только один поток…)
Соответственно, желательно определить ‘;’ следующим образом:
\ завершить текущее определение
: ; ( --> )
тут обычные действия
;CREATE
;

А в случаях, когда нельзя по умолчанию выполнять ;CREATE проставлять его в тексте программы принудительно:
CREATE ZZZ  128 ALLOT  ;CREATE

Так же ссылка на незавершенное слово будет невозможна до встречи ;CREATE.

Компиляция в нелинейно распределяемую память
Используя стандартный механизм HERE ALLOT можно распределять не только в линейных непрерывных областях памяти (например в ХИП). Для этого достаточно, чтобы слово HEADER при работе с такой памятью выделяло в ней достаточного размера буфер, а слово ;CREATE урезало этот буфер до необходимого размера, либо, необходимо в процессе работы научить слово ALLOT увеличивать размер используемого блока. Причем, наиболее логично делать и то и другое:
1. HEADER создает блок фиксированного размера и направляет на него HERE
2. производится сохранение данных в пространство блока памяти
3. ALLOT при превышении размера блока самостоятельно увеличивает его
4. по завершении вызывается ;CREATE , после которого фиксируется действительный адрес блока, после чего в памяти блок перемещать уже нельзя.

Литература:


1. mOleg Что такое словарь
2. Джеф Фокс Суть Форта
3. mOleg SPF Fork


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Сб ноя 14, 2009 17:34 
Не в сети

Зарегистрирован: Вт май 09, 2006 12:31
Сообщения: 3438
Благодарил (а): 5 раз.
Поблагодарили: 16 раз.
Цитата:
A) собирать определение в отдельном участке памяти, уникальном для данного потока, и после завершения сборки переносить код в общее пространство;
Возникает несколько туповаты вопрос, для всех ли типов шитого кода такой подход возможен


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Сб ноя 14, 2009 17:48 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
вопрос писал(а):
Возникает несколько туповаты вопрос, для всех ли типов шитого кода такой подход возможен

да, для любого.

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн ноя 16, 2009 12:16 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
одна из наиболе сложных и часто встречающихся задач при написании программ:
где и как разместить данные,
что делать с увеличивающимися объемами данных,
как во время освободить ресурсы, занимаемые ненужными данными.

Эти вопросы решаются с различной успешностью в различных языках и системах программирования. Решение этих проблем привело к появлению баз данных, сборки мусора, динамической памяти ("Хип-а" или как еще называют "Кучи"), появлению стеков, деков, каналов, и пр. Параллельная обработка данных еще сильнее обострила эти проблемы, потребовала создания различных объектов синхронизации (семафоров, мьютексов). Много проблем создают вопросы, связанные с хранением данных в различных хранилищах: больших и маленьких, быстрых и медленных, локальных и удаленных, доступных только на чтение, на запись. А так же вопросы безопасности, то есть разрешения работы с данными. Многие из вопросов носят совсем не инженерный характер: этика к примеру.

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

Пока что я могу констатировать факт, что Форт сравнительно удачно работает с памятью на однозадачных системах небольшим количеством памяти без особых заморочек с защитой (что является обратной стороной простоты используемых механизмов и открытости системы). Хотя я не считаю эти проблемы не разрешимыми в рамках Форта. К сожалению я не встречал серьезных работ, посвященных разрешению перечисленных проблем в Форте(возможно, кто-то может поделиться таковыми).

Вектор развития вычислительных систем явно направлен в сторону многопоточных многопроцессорных распределенных систем. И Форту придется либо развиваться, то есть меняться, с учетом происходящего, либо...

Собственно, обсуждаемая статья "прошлась по верхам" проблем.

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн ноя 16, 2009 19:10 
Не в сети
Аватара пользователя

Зарегистрирован: Вт авг 12, 2008 03:18
Сообщения: 327
Откуда: Москва
Благодарил (а): 36 раз.
Поблагодарили: 7 раз.
А что говорит стандарт о паралельных процессах, которые должны взаимодействовать между собой?
Или отдает на рассмотрение разработчикам фортов. Если так, то катастрофа :weep;

_________________
Линукс решает, винда глотает.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн ноя 16, 2009 21:28 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
vikt писал(а):
А что говорит стандарт о паралельных процессах

на самом деле это не принципиально. Важно не то, что говорит стандарт, а что уже есть в Форт-системах.

vikt писал(а):
которые должны взаимодействовать между собой?

вот о взаимодействии, на сколько я осведомлен ничего вообще не сказано.
Есть как раз часть разделения процессов:создание и запуск параллельного потока и создание и работа с уникальными для каждого процесса переменными (USER область).

vikt писал(а):
Или отдает на рассмотрение разработчикам фортов. Если так, то катастрофа

ну, стандарт нужно всеравно новый делать, в том числе и по этой причине.

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн ноя 16, 2009 22:00 
Не в сети
Аватара пользователя

Зарегистрирован: Вт авг 12, 2008 03:18
Сообщения: 327
Откуда: Москва
Благодарил (а): 36 раз.
Поблагодарили: 7 раз.
Тогда наверно проще, если не нужно взаимодействовать.
Если форт реализуется на языках высокого уровня, то для
каждого процесса можно создать свои указатели на структуры данных,
если для современных процессоров, например 386, там каждому процессу выделяется
виртуальная память 0 до 4 гб, при обращение к адрессу, который физически
отсутствует в памяти, происходит прерывание итд.

_________________
Линукс решает, винда глотает.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт ноя 19, 2009 10:32 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
Я бы отделил слова HERE и ALLOT. Они базовые, остальные реализуются через них. Сказал бы пару слов об отрицательном параметре ALLOT.
И релизацию , привел бы как пример остальных слов, список которых бы и привел рядом (C, S,).


mOleg писал(а):
Каждый кусок кода и данных (обычно) связан с конкретным именем, и может быть вызван по имени.
Я бы добавил "по этому имени".

mOleg писал(а):
Исключением являются :NONAME определения, но не во всех Форт-системах они существуют, и далеко не всегда совсем не имеют поля имени.

Что хотел сказать, куда акцент?
Зачем так много слов "приблизительности" - "далеко", "не всегда", "совсем".
Можно сказать это как-то проще? ;)

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт ноя 19, 2009 11:03 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
in4 писал(а):
Я бы отделил слова HERE и ALLOT. Они базовые, остальные реализуются через них.

я не понял о чем ты

in4 писал(а):
Сказал бы пару слов об отрицательном параметре ALLOT.

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

in4 писал(а):
И релизацию , привел бы как пример остальных слов, список которых бы и привел рядом (C, S,).

она, реализаиця, зависит от хранилища.

in4 писал(а):
mOleg писал(а):Исключением являются :NONAME определения, но не во всех Форт-системах они существуют, и далеко не всегда совсем не имеют поля имени.

Что хотел сказать, куда акцент?
Зачем так много слов "приблизительности" - "далеко", "не всегда", "совсем".
Можно сказать это как-то проще?

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

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт ноя 19, 2009 14:30 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
mOleg писал(а):
in4 писал(а):
Я бы отделил слова HERE и ALLOT. Они базовые, остальные реализуются через них.
я не понял о чем ты

Там у тебя подряд описание 3х слов - HERE ALLOT ,
Я бы отделил первые 2 - они взаимодополняющие и взаимозависимые.
"," реализуется через них и может рассматриваться как следующий уровень, основанный на предыдущем.

mOleg писал(а):
обычно любой кусок кода и данных связан с именем (иногда несколькими). А другие варианты хоть и существуют, но носят не регулярный характер.
Так и скажи там, это проще для понимания... ;)
Может, правда, не "кусок" а "часть" или "фрагмент".

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт ноя 20, 2009 21:25 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
in4 писал(а):
Там у тебя подряд описание 3х слов - HERE ALLOT ,
Я бы отделил первые 2 - они взаимодополняющие и взаимозависимые.

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

С другой стороны я пропустил описание слов ! @ хотя от них тоже зависит методика работы с пространством кода и данных.
вобщем, я не считаю полученный вариант окончательным, и много еще мне самому надо переосмыслить (свести воедино разные размышления и наблюдения) Возможно, все же стоило начинать с доступа к памяти.

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср мар 10, 2010 21:51 
Не в сети
Аватара пользователя

Зарегистрирован: Пт дек 26, 2008 21:16
Сообщения: 412
Откуда: Великий Новгород
Благодарил (а): 9 раз.
Поблагодарили: 4 раз.
Пожалуйста объясните мне бесталковому :oops: зачем все таки нужна многопоточная компиляция.
Только просьба приводить не теоретические размышления, а те случаи где обязательно необходимо
компилировать из нескольких потоков или где без этого трудно обойтись.
А то столько сложностей :roll: а для чего не понятно.??? :shuffle;


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт мар 11, 2010 09:46 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
_Harry писал(а):
Пожалуйста объясните мне бесталковому зачем все таки нужна многопоточная компиляция.

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

_Harry писал(а):
А то столько сложностей а для чего не понятно.???

на самом деле сложностей я не вижу, достаточно введения простейших объектов синхронизации (мьютексов), которые не будут позволять сразу нескольким потокам создавать определения (так сделано в форке). Есть и более "продвинутые" варианты, но их уже делать только при серьезной необходимости.

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт мар 11, 2010 11:47 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
mOleg писал(а):
_Harry писал(а):
Пожалуйста объясните мне бесталковому зачем все таки нужна многопоточная компиляция.

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

Читая словосочетание "многопоточная компиляция", создается впечатление, что речь идет о компиляции, которая специально раздается на несколько потоков. Сейчас же выяснилось, что имелась в виду ситуация, когда несколько потоков независимо друг от друга решили компилировать. А это все же неочевидно, если упирать на "проблемы при многопоточной компиляции".
mOleg писал(а):
на самом деле сложностей я не вижу, достаточно введения простейших объектов синхронизации (мьютексов), которые не будут позволять сразу нескольким потокам создавать определения (так сделано в форке). Есть и более "продвинутые" варианты, но их уже делать только при серьезной необходимости.

А почему же тогда проблемы с BASE выделяются отдельной строкой? Начнем тогда уж с того, что подобные переменные должны иметь копию для каждого потока, а то ведь можно и к STATE предъявить аналогичные претензии и сказать, что она не может быть глобальной, иначе каждый поток ее дернет в свою сторону. А вообще можно вспомнить, что многопоточность в виде переключения адресного интерпретатора рассматривалась еще у Баранова в качестве дешевой альтернативы многозадачности. Спрашивается, чем хуже многозадачность, в свете того, что надо прилагать такие усилия для обеспечения безглючности потоков?


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт мар 11, 2010 14:11 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
Хищник писал(а):
Читая словосочетание "многопоточная компиляция", создается впечатление, что речь идет о компиляции, которая специально раздается на несколько потоков.

да, возможно термин не слишком удачно подобран. Речь идет о том, что несколько потоков одновременно создают код в одном и том же пространстве данных\кода.
Хищник писал(а):
А это все же неочевидно, если упирать на "проблемы при многопоточной компиляции".

можно предложить ваш вариант названия.
а "распределять" задачу сборки одного определения по нескольким потокам, ну как бы несколько эксцентрично ;)

Хищник писал(а):
А почему же тогда проблемы с BASE выделяются отдельной строкой?

BASE вообще в другой теме, вопросы лучше туда.

Хищник писал(а):
Начнем тогда уж с того, что подобные переменные должны иметь копию для каждого потока, а то ведь можно и к STATE предъявить аналогичные претензии и сказать, что она не может быть глобальной, иначе каждый поток ее дернет в свою сторону.

"ээ, дарагой!" не надо все-таки путать переменные типа BASE STATE c DP - у них разная природа.
DP (т.е. HERE) глобален для всех потоков (обычно) и USER переменной его не сделаешь.

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

тут ведь по правилам надо рассмотреть все возможные типы многозадачности и все варианты организации памяти систем.
Проблемы синхронизации процессов при "кольцевой многопоточности" (ROUND-ROBIN), описанной у Баранова и используемой во многих Форт-системах не так остры (хотя никуда и не уходят), чем в, ну давайте назовем, виндошной многопоточности (то есть случае, когда прерывается выполнение потока по таймеру в произвольные моменты времени и все потоки процесса разделяют основные блоки кода и данных). Так же, если вспомнить как устроена многозадачность в unix и подобных системах, можно убедиться, что возникают уже другие проблемы, в то время как проблем с DP вообще не будет(т.к. адресные пространства у "форкнутых" потоков не будут пересекаться).

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 28 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 13


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB