Автор |
Сообщение |
|
|
Заголовок сообщения: |
|
|
|
1 - mOleg писал(а): Трансляция скриптов в веб-сервере к примеру. 2 - mOleg писал(а): Если захочется создать многопользовательскую БД на основе словарей, так же будет возможность добавления знаний от нескольких пользователей.
А вот нет тут необходимости в многопоточной компиляции.
Первый случай - Нужен каждому свой изолированый процесс.
Представляю себе что совместно накомпилируют пользователи веб-сервера если они даже не подозревают друг о друге.
Второй случай - тут есть применение многопоточности но логичней процесс компиляции отдать основному потоку.
Пусть он и разруливает запросы от потоков.
( Да и разделить пространства ядра и пользовательской БД имеет смысл т.е. у БД свои DP, LAST, и т.п.
А еще каждому пользователю свое пространство имен понадобится для тех же запросов бр...... не нравится мне все это)
1 - [quote="mOleg"]Трансляция скриптов в веб-сервере к примеру.[/quote] 2 - [quote="mOleg"]Если захочется создать многопользовательскую БД на основе словарей, так же будет возможность добавления знаний от нескольких пользователей.[/quote]
А вот нет тут необходимости в многопоточной компиляции.
Первый случай - Нужен каждому свой изолированый процесс.
Представляю себе что совместно накомпилируют пользователи веб-сервера если они даже не подозревают друг о друге.
Второй случай - тут есть применение многопоточности но логичней процесс компиляции отдать основному потоку.
Пусть он и разруливает запросы от потоков.
( Да и разделить пространства ядра и пользовательской БД имеет смысл т.е. у БД свои DP, LAST, и т.п.
А еще каждому пользователю свое пространство имен понадобится для тех же запросов бр...... не нравится мне все это)
|
|
|
|
Добавлено: Пт мар 12, 2010 11:42 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): вот, зависит от типа многозадачности, используемой в системе и организации памяти. И тебе, если захочется безглючности, всеравно придется их учитывать. Всего учесть все равно не удастся. А если многозадачность сама по себе небезопасная, то почему надо не ее ограничивать (или хотя бы предупреждать о возможных последствиях), а ломать структуры, которые сами по себе никакого отношения к многозадачности не имеют? mOleg писал(а): Если ты используешь однопоточную по своей природе систему, тебе придется переписать пол транслятора (если вообще не весь) для обеспечения многозадачности, Ты уверен, что правильно применяешь понятия process и thread? Несколько threads в одном процессе - это у тебя многозадачность или многопоточность? Множество process одного типа - это вообще не проблема, это независимые экземпляры одной и той же программы. "Обеспечивать многозадачность" при этом не нужно - это делает ОС. А многопоточность сама, от сырости, не заведется, второй поток должен кто-то запустить. Так почему это должно быть сделано в стиле "мыши плакали, кололись, но продолжали жрать кактус"? mOleg писал(а): есть ощущение, что Хищник либо не понимает о чем речь, либо вредничает. вопрос о методике клонирования работающего потока с помощью fork (линуксевого) в результате которого запускается копия процесса (тут объяснять не буду, лучше почитай сам, как организована многозадачность в линуксе). Да нет, это у тебя идет чересполосица с терминами. То задача, то поток. Ты уж определись, задача или поток, и не перемешивай аргументы. Есть свойства и характеристики задачи (process), и есть - потока (thread). http://msdn.microsoft.com/en-us/library/ms684841(VS.85).aspx Цитата: An application consists of one or more processes. A process, in the simplest terms, is an executing program. One or more threads run in the context of the process. A thread is the basic unit to which the operating system allocates processor time. A thread can execute any part of the process code, including parts currently being executed by another thread. mOleg писал(а): в винде это сделать нормально не получается, я знаю только один достаточно тяжелый вариант: сохранить систему в исполнимый файл на диск, и запустить его с помощью exec , однако такой подход несколько тяжеловат. http://msdn.microsoft.com/en-us/library/ms682516(VS.85).aspx Цитата: The CreateThread function creates a new thread for a process. The creating thread must specify the starting address of the code that the new thread is to execute. Typically, the starting address is the name of a function defined in the program code (for more information, see ThreadProc). This function takes a single parameter and returns a DWORD value. A process can have multiple threads simultaneously executing the same function.
То, о чем ты пишешь, с запуском еще одного файла, есть создание процесса, а не потока. Но опять-таки, копия программы - это вообще не вопрос для обсуждения. Хоть однопоточная, хоть многопоточная, за разделением ресурсов следит ОС. Многопоточность же обеспечивает программист, и это отдельный класс программ. Спрашивается, что в действительности требуется от Форта и какие полезные свойства должны быть привнесены многопоточностью? Не кроется ли за этим желание пускать несколько копий Форта (что вообще не проблема), или же стремление убрать "тяжелые" расчеты в отдельный thread? Но тогда вновь создаваемый поток либо будет правильно спроектирован, либо он может наломать дров и с учетом переноса глобальных переменных в локальную область (три раза ха - если поток полезет в чужую память, то какая ему разница, глобальное значение хранит эта ячейка или локальное?).
[quote="mOleg"]вот, зависит от типа многозадачности, используемой в системе и организации памяти. И тебе, если захочется безглючности, всеравно придется их учитывать.[/quote] Всего учесть все равно не удастся. А если многозадачность сама по себе небезопасная, то почему надо не ее ограничивать (или хотя бы предупреждать о возможных последствиях), а ломать структуры, которые сами по себе никакого отношения к многозадачности не имеют? [quote="mOleg"]Если ты используешь однопоточную по своей природе систему, тебе придется переписать пол транслятора (если вообще не весь) для обеспечения многозадачности,[/quote] Ты уверен, что правильно применяешь понятия process и thread? Несколько threads в одном процессе - это у тебя многозадачность или многопоточность? Множество process одного типа - это вообще не проблема, это независимые экземпляры одной и той же программы. "Обеспечивать многозадачность" при этом не нужно - это делает ОС. А многопоточность сама, от сырости, не заведется, второй поток должен кто-то запустить. Так почему это должно быть сделано в стиле "мыши плакали, кололись, но продолжали жрать кактус"? [quote="mOleg"]есть ощущение, что Хищник либо не понимает о чем речь, либо вредничает. вопрос о методике клонирования работающего потока с помощью fork (линуксевого) в результате которого запускается копия процесса (тут объяснять не буду, лучше почитай сам, как организована многозадачность в линуксе).[/quote] Да нет, это у тебя идет чересполосица с терминами. То задача, то поток. Ты уж определись, задача или поток, и не перемешивай аргументы. Есть свойства и характеристики задачи (process), и есть - потока (thread).
http://msdn.microsoft.com/en-us/library/ms684841(VS.85).aspx [quote]An application consists of one or more processes. A process, in the simplest terms, is an executing program. One or more threads run in the context of the process. A thread is the basic unit to which the operating system allocates processor time. A thread can execute any part of the process code, including parts currently being executed by another thread. [/quote]
[quote="mOleg"]в винде это сделать нормально не получается, я знаю только один достаточно тяжелый вариант: сохранить систему в исполнимый файл на диск, и запустить его с помощью exec , однако такой подход несколько тяжеловат. [/quote] http://msdn.microsoft.com/en-us/library/ms682516(VS.85).aspx [quote]The CreateThread function creates a new thread for a process. The creating thread must specify the starting address of the code that the new thread is to execute. Typically, the starting address is the name of a function defined in the program code (for more information, see ThreadProc). This function takes a single parameter and returns a DWORD value. A process can have multiple threads simultaneously executing the same function. [/quote]
То, о чем ты пишешь, с запуском еще одного файла, есть создание процесса, а не потока. Но опять-таки, копия программы - это вообще не вопрос для обсуждения. Хоть однопоточная, хоть многопоточная, за разделением ресурсов следит ОС. Многопоточность же обеспечивает программист, и это отдельный класс программ. Спрашивается, что в действительности требуется от Форта и какие полезные свойства должны быть привнесены многопоточностью? Не кроется ли за этим желание пускать несколько копий Форта (что вообще не проблема), или же стремление убрать "тяжелые" расчеты в отдельный thread? Но тогда вновь создаваемый поток либо будет правильно спроектирован, либо он может наломать дров и с учетом переноса глобальных переменных в локальную область (три раза ха - если поток полезет в чужую память, то какая ему разница, глобальное значение хранит эта ячейка или локальное?).
|
|
|
|
Добавлено: Пт мар 12, 2010 10:33 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): mOleg писал(а): при том, что речь идет о "возможности одновременной компиляции в нескольких потоках", что само собой затрагивает глобальные переменные DP и LAST.
Это, вобщем-то, достаточно тривиальное наблюдение, и я про него даже и не упоминал. Очевидно, что потоки, которые хотят компилировать в одну область памяти, обязаны пользоваться одним DP но подразумевал Хищник писал(а): Но к BASE-то такого требования нет, да и ко многим другим переменным нет, в том числе тем, которые будут появляться в процессе разработки программы. Если я, как прикладной программист, запускаю какое-то слово из библиотеки, а оно, оказывается, создает еще один поток, но почему я-то должен в своем коде обеспечивать сосуществование потоков? вот, зависит от типа многозадачности, используемой в системе и организации памяти. И тебе, если захочется безглючности, всеравно придется их учитывать. С другой стороны не стоит путать проработку структур ядра Форт-системы и пользовательской задачи, т.к. первое должно быть более надежным уже в силу возможности использования его в большом количестве пользовательских задач. Вообще, иногда вещи легко навешиваются в виде библиотек поверх уже готовой системы, а иногда проще получается, когда такие вещи интегрированы в ядро. Если ты используешь однопоточную по своей природе систему, тебе придется переписать пол транслятора (если вообще не весь) для обеспечения многозадачности, в обратном случае, когда система заточена под многопоточность, использовать транслятор для работы в однопоточном режиме не сложно. Хищник писал(а): mOleg писал(а): только две копии транслятора имеются не всегда. Я был бы очень признателен Хищнику, если бы он показал, как можно запускать параллельный процесс под виндой Эээ... мне что, скриншот сделать, что ли? есть ощущение, что Хищник либо не понимает о чем речь, либо вредничает. вопрос о методике клонирования работающего потока с помощью fork (линуксевого) в результате которого запускается копия процесса (тут объяснять не буду, лучше почитай сам, как организована многозадачность в линуксе). в винде это сделать нормально не получается, я знаю только один достаточно тяжелый вариант: сохранить систему в исполнимый файл на диск, и запустить его с помощью exec , однако такой подход несколько тяжеловат. Хищник писал(а): Под Windows можно запустить несколько копий одной и той же программы. Для этого сама программа не обязана знать, сколько ее копий запущено - у нее будет полный комплект ее памяти, и никто эту память не тронет.
это не одно и тоже. Точнее, это совсем другое.
[quote="Хищник"]mOleg писал(а): при том, что речь идет о "возможности одновременной компиляции в нескольких потоках", что само собой затрагивает глобальные переменные DP и LAST.
Это, вобщем-то, достаточно тривиальное наблюдение, и я про него даже и не упоминал. Очевидно, что потоки, которые хотят компилировать в одну область памяти, обязаны пользоваться одним DP[/quote] но подразумевал ;)
[quote="Хищник"]Но к BASE-то такого требования нет, да и ко многим другим переменным нет, в том числе тем, которые будут появляться в процессе разработки программы. Если я, как прикладной программист, запускаю какое-то слово из библиотеки, а оно, оказывается, создает еще один поток, но почему я-то должен в своем коде обеспечивать сосуществование потоков?[/quote] вот, зависит от типа многозадачности, используемой в системе и организации памяти. И тебе, если захочется безглючности, всеравно придется их учитывать. С другой стороны не стоит путать проработку структур ядра Форт-системы и пользовательской задачи, т.к. первое должно быть более надежным уже в силу возможности использования его в большом количестве пользовательских задач.
Вообще, иногда вещи легко навешиваются в виде библиотек поверх уже готовой системы, а иногда проще получается, когда такие вещи интегрированы в ядро. Если ты используешь однопоточную по своей природе систему, тебе придется переписать пол транслятора (если вообще не весь) для обеспечения многозадачности, в обратном случае, когда система заточена под многопоточность, использовать транслятор для работы в однопоточном режиме не сложно.
[quote="Хищник"]mOleg писал(а): только две копии транслятора имеются не всегда. Я был бы очень признателен Хищнику, если бы он показал, как можно запускать параллельный процесс под виндой Эээ... мне что, скриншот сделать, что ли?[/quote] есть ощущение, что Хищник либо не понимает о чем речь, либо вредничает. вопрос о методике клонирования работающего потока с помощью fork (линуксевого) в результате которого запускается копия процесса (тут объяснять не буду, лучше почитай сам, как организована многозадачность в линуксе). в винде это сделать нормально не получается, я знаю только один достаточно тяжелый вариант: сохранить систему в исполнимый файл на диск, и запустить его с помощью exec , однако такой подход несколько тяжеловат. [quote="Хищник"]Под Windows можно запустить несколько копий одной и той же программы. Для этого сама программа не обязана знать, сколько ее копий запущено - у нее будет полный комплект ее памяти, и никто эту память не тронет.[/quote]
это не одно и тоже. Точнее, это совсем другое.
|
|
|
|
Добавлено: Пт мар 12, 2010 05:27 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
_Harry писал(а): Вот который раз прошу объяснить, а кому это хоть раз понадобилось, или хоть укажи на ситуацию где может возникнуть необходимость компилировать код не из главного потока. Трансляция скриптов в веб-сервере к примеру. Если захочется создать многопользовательскую БД на основе словарей, так же будет возможность добавления знаний от нескольких пользователей. _Harry писал(а): или хоть укажи на ситуацию где может возникнуть необходимость компилировать код не из главного потока.
если немного размечтаться ( ) и вспомнить о том, что нативный форт может использоваться как вариант операционной системы, то так же возможна встреча с многозадачностью, а значит, возможностью добавления кода разными потоками\процессами кода, особенно, если Форт-система достаточно простая и не заморачивается со всякими хитрыми методиками работы с памятью.
Лично мне важнее даже не сама возможность компилировать код в нескольких потоках, а обеспечение транзакций нормальных на уровне ядра форт-системы.
[quote="_Harry"]Вот который раз прошу объяснить, а кому это хоть раз понадобилось, или хоть укажи на ситуацию где может возникнуть необходимость компилировать код не из главного потока.[/quote] Трансляция скриптов в веб-сервере к примеру. Если захочется создать многопользовательскую БД на основе словарей, так же будет возможность добавления знаний от нескольких пользователей.
[quote="_Harry"]или хоть укажи на ситуацию где может возникнуть необходимость компилировать код не из главного потока.[/quote]
если немного размечтаться ( 8) ) и вспомнить о том, что нативный форт может использоваться как вариант операционной системы, то так же возможна встреча с многозадачностью, а значит, возможностью добавления кода разными потоками\процессами кода, особенно, если Форт-система достаточно простая и не заморачивается со всякими хитрыми методиками работы с памятью.
Лично мне важнее даже не сама возможность компилировать код в нескольких потоках, а обеспечение транзакций нормальных на уровне ядра форт-системы.
|
|
|
|
Добавлено: Пт мар 12, 2010 05:15 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): при том, что речь идет о "возможности одновременной компиляции в нескольких потоках", что само собой затрагивает глобальные переменные DP и LAST. Это, вобщем-то, достаточно тривиальное наблюдение, и я про него даже и не упоминал. Очевидно, что потоки, которые хотят компилировать в одну область памяти, обязаны пользоваться одним DP. Но к BASE-то такого требования нет, да и ко многим другим переменным нет, в том числе тем, которые будут появляться в процессе разработки программы. Если я, как прикладной программист, запускаю какое-то слово из библиотеки, а оно, оказывается, создает еще один поток, но почему я-то должен в своем коде обеспечивать сосуществование потоков? mOleg писал(а): только две копии транслятора имеются не всегда. Я был бы очень признателен Хищнику, если бы он показал, как можно запускать параллельный процесс под виндой Эээ... мне что, скриншот сделать, что ли? mOleg писал(а): таким же образом, как это происходит под линуксом
Неужто пингвиненка нарисовать? Я не понимаю контекста утверждения "таким же образом". Под Windows можно запустить несколько копий одной и той же программы. Для этого сама программа не обязана знать, сколько ее копий запущено - у нее будет полный комплект ее памяти, и никто эту память не тронет. Мне действительно надо показать процесс запуска двух экземпляров транслятора с объявлением там одинаковой переменной и установкой ее в разные значения в разных экземплярах?
[quote="mOleg"]при том, что речь идет о "возможности одновременной компиляции в нескольких потоках", что само собой затрагивает глобальные переменные DP и LAST. [/quote] Это, вобщем-то, достаточно тривиальное наблюдение, и я про него даже и не упоминал. Очевидно, что потоки, которые хотят компилировать в одну область памяти, обязаны пользоваться одним DP. Но к BASE-то такого требования нет, да и ко многим другим переменным нет, в том числе тем, которые будут появляться в процессе разработки программы. Если я, как прикладной программист, запускаю какое-то слово из библиотеки, а оно, оказывается, создает еще один поток, но почему я-то должен в своем коде обеспечивать сосуществование потоков? [quote="mOleg"]только две копии транслятора имеются не всегда. Я был бы очень признателен Хищнику, если бы он показал, как можно запускать параллельный процесс под виндой[/quote] Эээ... мне что, скриншот сделать, что ли? [quote="mOleg"]таким же образом, как это происходит под линуксом[/quote]
Неужто пингвиненка нарисовать? :)) Я не понимаю контекста утверждения "таким же образом". Под Windows можно запустить несколько копий одной и той же программы. Для этого сама программа не обязана знать, сколько ее копий запущено - у нее будет полный комплект ее памяти, и никто эту память не тронет. Мне действительно надо показать процесс запуска двух экземпляров транслятора с объявлением там одинаковой переменной и установкой ее в разные значения в разных экземплярах?
|
|
|
|
Добавлено: Чт мар 11, 2010 17:46 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): mOleg писал(а): нигде не упоминал. Но именно DP связано с обсуждаемым вопросом. Т.е. имеется единое хранилище кода\данных, единый для разных потоков словарь(и) и эти вещи завязаны на переменные: DP и LAST как минимум. Опять, же, эти вещи просто находятся в контексте обсуждения Замечательно! Приписать оппоненту утверждение, которого он не делал, но которое заведомо легко разбивается в пух и прах я отвечал на: Хищник писал(а): А почему же тогда проблемы с BASE выделяются отдельной строкой? Начнем тогда уж с того, что подобные переменные должны иметь копию для каждого потока, а то ведь можно и к STATE предъявить аналогичные претензии и сказать, что она не может быть глобальной, иначе каждый поток ее дернет в свою сторону. при том, что речь идет о "возможности одновременной компиляции в нескольких потоках", что само собой затрагивает глобальные переменные DP и LAST. Хищник писал(а): mOleg писал(а): С другой стороны, многопоточность уже есть в Форте, и существует давно, так почему же ее не сделать бездефектной? Бездефектной - значит не затрагивающей уже сложившиеся механизмы, которые к многопоточности вообще никакого отношения не имеют. а вот тут как раз речь идет о том, чтобы интерфейсы (т.е. имена и параметры слов) остались привычными. Хищник писал(а): mOleg писал(а): проблема уже есть, нельзя сказать, что она носит принципиальный характер Конечно же, она его не носит. Потому что две копии транслятора в разных задачах имеют собственные набора кода и данных, и никакие переключения и асинхронные события им не страшны.
только две копии транслятора имеются не всегда.
Я был бы очень признателен Хищнику, если бы он показал, как можно запускать параллельный процесс под виндой, таким же образом, как это происходит под линуксом Пока же мы имеем виндошную многопоточность в том же СПФе, win32Forth.
[quote="Хищник"]mOleg писал(а): нигде не упоминал. Но именно DP связано с обсуждаемым вопросом. Т.е. имеется единое хранилище кода\данных, единый для разных потоков словарь(и) и эти вещи завязаны на переменные: DP и LAST как минимум. Опять, же, эти вещи просто находятся в контексте обсуждения Замечательно! Приписать оппоненту утверждение, которого он не делал, но которое заведомо легко разбивается в пух и прах [/quote] я отвечал на: [quote="Хищник"] А почему же тогда проблемы с BASE выделяются отдельной строкой? Начнем тогда уж с того, что подобные переменные должны иметь копию для каждого потока, а то ведь можно и к STATE предъявить аналогичные претензии и сказать, что она не может быть глобальной, иначе каждый поток ее дернет в свою сторону.[/quote] при том, что речь идет о "возможности одновременной компиляции в нескольких потоках", что само собой затрагивает глобальные переменные DP и LAST.
[quote="Хищник"]mOleg писал(а): С другой стороны, многопоточность уже есть в Форте, и существует давно, так почему же ее не сделать бездефектной? Бездефектной - значит не затрагивающей уже сложившиеся механизмы, которые к многопоточности вообще никакого отношения не имеют.[/quote] а вот тут как раз речь идет о том, чтобы интерфейсы (т.е. имена и параметры слов) остались привычными.
[quote="Хищник"]mOleg писал(а): проблема уже есть, нельзя сказать, что она носит принципиальный характер Конечно же, она его не носит. Потому что две копии транслятора в разных задачах имеют собственные набора кода и данных, и никакие переключения и асинхронные события им не страшны. [/quote]
только две копии транслятора имеются не всегда.
Я был бы очень признателен Хищнику, если бы он показал, как можно запускать параллельный процесс под виндой, таким же образом, как это происходит под линуксом ;) Пока же мы имеем виндошную многопоточность в том же СПФе, win32Forth.
|
|
|
|
Добавлено: Чт мар 11, 2010 17:14 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
_Harry писал(а): и Арина Родионовна рядом (с двумя кружками)
Это уже многопоточность :))
[quote="_Harry"]и Арина Родионовна рядом (с двумя кружками)[/quote]
Это уже [b]многопоточность [/b]:)) :)) :))
|
|
|
|
Добавлено: Чт мар 11, 2010 16:31 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): "это мне не нужно, значит это ерунда". Вот который раз прошу объяснить, а кому это хоть раз понадобилось, или хоть укажи на ситуацию где может возникнуть необходимость компилировать код не из главного потока. Мне представляется только одно несколько человек с разных терминалов пишут код одной системы Не хотел бы я быть одним из них. Лебедь рак и щука однако... mOleg писал(а): часто хватает калькулятора и пищущей машинки
Не еще лучше гусиное перо чернильница и Арина Родионовна рядом (с двумя кружками)
[quote="mOleg"]"это мне не нужно, значит это ерунда".[/quote] Вот который раз прошу объяснить, а кому это хоть раз понадобилось, или хоть укажи на ситуацию где может возникнуть необходимость компилировать код не из главного потока. Мне представляется только одно несколько человек с разных терминалов пишут код одной системы :shock: Не хотел бы я быть одним из них. :? Лебедь рак и щука однако...
[quote="mOleg"]часто хватает калькулятора и пищущей машинки [/quote]
Не еще лучше :roll: гусиное перо чернильница и Арина Родионовна рядом (с двумя кружками)
|
|
|
|
Добавлено: Чт мар 11, 2010 16:20 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): Если честно, у меня просто не проходит подозрение, что вы не внимательно читаете текст (либо предвзято, что тоже не способствует адекватности его восприятия). Дело в том, что как минимум 4 человека восприняли термин "многопоточная компиляция" одинаковым образом - как компиляцию, раздаваемую на несколько потоков. "Все идут не в ногу"? mOleg писал(а): нигде не упоминал. Но именно DP связано с обсуждаемым вопросом. Т.е. имеется единое хранилище кода\данных, единый для разных потоков словарь(и) и эти вещи завязаны на переменные: DP и LAST как минимум. Опять, же, эти вещи просто находятся в контексте обсуждения Замечательно! Приписать оппоненту утверждение, которого он не делал, но которое заведомо легко разбивается в пух и прах mOleg писал(а): ну, вопрос в том, чего же Хищник хочет от Форта (и не только Хищник ) То, что "хотелки" у разных людей не обязательно совпадают - это ведь нормально! Но это не означает, что все согласятся отказаться от используемых подходов ради того, чего в исходной постановке не было. mOleg писал(а): С другой стороны, многопоточность уже есть в Форте, и существует давно, так почему же ее не сделать бездефектной? Бездефектной - значит не затрагивающей уже сложившиеся механизмы, которые к многопоточности вообще никакого отношения не имеют. mOleg писал(а): Т.е. я не понимаю подхода "это мне не нужно, значит это ерунда". "Мне не нужна глобальная BASE, значит глобальная BASE ерунда"? mOleg писал(а): проблема уже есть, нельзя сказать, что она носит принципиальный характер
Конечно же, она его не носит. Потому что две копии транслятора в разных задачах имеют собственные набора кода и данных, и никакие переключения и асинхронные события им не страшны. Зачем же придумывать гипотетические ситуации, которые могут появиться в основном от непонимания всех последствий их создания (но которые, возможно, внушительно и красиво звучат)? Если программист собирается организовать именно многопоточность (с общим пространством данных), то ему и заботиться о корректном взаимодействии потоков. Почему ради ликвидации последствий его возможной невнимательности должны страдать программисты, решающие существенно более простые задачи?
[quote="mOleg"]Если честно, у меня просто не проходит подозрение, что вы не внимательно читаете текст (либо предвзято, что тоже не способствует адекватности его восприятия). [/quote] Дело в том, что как минимум 4 человека восприняли термин "многопоточная компиляция" одинаковым образом - как компиляцию, раздаваемую на несколько потоков. "Все идут не в ногу"? [quote="mOleg"]нигде не упоминал. Но именно DP связано с обсуждаемым вопросом. Т.е. имеется единое хранилище кода\данных, единый для разных потоков словарь(и) и эти вещи завязаны на переменные: DP и LAST как минимум. Опять, же, эти вещи просто находятся в контексте обсуждения [/quote] Замечательно! :) Приписать оппоненту утверждение, которого он не делал, но которое заведомо легко разбивается в пух и прах :)) [quote="mOleg"]ну, вопрос в том, чего же Хищник хочет от Форта (и не только Хищник ) То, что "хотелки" у разных людей не обязательно совпадают - это ведь нормально! [/quote] Но это не означает, что все согласятся отказаться от используемых подходов ради того, чего в исходной постановке не было.
[quote="mOleg"]С другой стороны, многопоточность уже есть в Форте, и существует давно, так почему же ее не сделать бездефектной? [/quote]
Бездефектной - значит не затрагивающей уже сложившиеся механизмы, которые к многопоточности вообще никакого отношения не имеют.
[quote="mOleg"]Т.е. я не понимаю подхода "это мне не нужно, значит это ерунда". [/quote] "Мне не нужна глобальная BASE, значит глобальная BASE ерунда"? :))
[quote="mOleg"]проблема уже есть, нельзя сказать, что она носит принципиальный характер[/quote]
Конечно же, она его не носит. Потому что две копии транслятора в разных задачах имеют собственные набора кода и данных, и никакие переключения и асинхронные события им не страшны. Зачем же придумывать гипотетические ситуации, которые могут появиться в основном от непонимания всех последствий их создания (но которые, возможно, внушительно и красиво звучат)? Если программист собирается организовать именно многопоточность (с общим пространством данных), то ему и заботиться о корректном взаимодействии потоков. Почему ради ликвидации последствий его возможной невнимательности должны страдать программисты, решающие существенно более простые задачи?
|
|
|
|
Добавлено: Чт мар 11, 2010 16:08 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): mOleg писал(а): а "распределять" задачу сборки одного определения по нескольким потокам, ну как бы несколько эксцентрично Дело в том, что именно эта эксцентричность и видится за предложенным термином Если честно, у меня просто не проходит подозрение, что вы не внимательно читаете текст (либо предвзято, что тоже не способствует адекватности его восприятия). Хищник писал(а): А можно показать пальцем на то место, где я хоть раз упоминал DP? нигде не упоминал. Но именно DP связано с обсуждаемым вопросом. Т.е. имеется единое хранилище кода\данных, единый для разных потоков словарь(и) и эти вещи завязаны на переменные: DP и LAST как минимум. Опять, же, эти вещи просто находятся в контексте обсуждения Хищник писал(а): По каким правилам, интересно? Форт - это ведь не язык, основным назначением которого является организация многозадачной/многопоточной работы. Если бы у него было так записано в "программном манифесте", то вот тогда и можно было бы рассматривать все внутренние механизмы через призму того, как оно ложится на любую разновидность многопоточности. А тут получается наоборот - у Форта уже есть некоторые базовые подходы, и теперь уже проблема программиста - увязать их с теми технологиями, которые ему хочется добавить в систему. ну, вопрос в том, чего же Хищник хочет от Форта (и не только Хищник ) То, что "хотелки" у разных людей не обязательно совпадают - это ведь нормально! С другой стороны, многопоточность уже есть в Форте, и существует давно, так почему же ее не сделать бездефектной? Т.е. я не понимаю подхода "это мне не нужно, значит это ерунда". Хищник писал(а): mOleg писал(а): то есть случае, когда прерывается выполнение потока по таймеру в произвольные моменты времени и все потоки процесса разделяют основные блоки кода и данных
Зачем создавать проблему, которую потом нужно будет доблестно преодолевать? Совместное использование кода и данных является источником проблем? "Не используйте код и данные совместно".
проблема уже есть, нельзя сказать, что она носит принципиальный характер, и ее разрешение ужастно необходимо.
в конце концов и компьютер нужен не всегда - часто хватает калькулятора и пищущей машинки
[quote="Хищник"]mOleg писал(а): а "распределять" задачу сборки одного определения по нескольким потокам, ну как бы несколько эксцентрично Дело в том, что именно эта эксцентричность и видится за предложенным термином [/quote] Если честно, у меня просто не проходит подозрение, что вы не внимательно читаете текст (либо предвзято, что тоже не способствует адекватности его восприятия).
[quote="Хищник"]А можно показать пальцем на то место, где я хоть раз упоминал DP?[/quote] нигде не упоминал. Но именно DP связано с обсуждаемым вопросом. Т.е. имеется единое хранилище кода\данных, единый для разных потоков словарь(и) и эти вещи завязаны на переменные: DP и LAST как минимум. Опять, же, эти вещи просто находятся в контексте обсуждения ;)
[quote="Хищник"]По каким правилам, интересно? Форт - это ведь не язык, основным назначением которого является организация многозадачной/многопоточной работы. Если бы у него было так записано в "программном манифесте", то вот тогда и можно было бы рассматривать все внутренние механизмы через призму того, как оно ложится на любую разновидность многопоточности. А тут получается наоборот - у Форта уже есть некоторые базовые подходы, и теперь уже проблема программиста - увязать их с теми технологиями, которые ему хочется добавить в систему.[/quote] ну, вопрос в том, чего же Хищник хочет от Форта (и не только Хищник 8) ) То, что "хотелки" у разных людей не обязательно совпадают - это ведь нормально! С другой стороны, многопоточность уже есть в Форте, и существует давно, так почему же ее не сделать бездефектной?
Т.е. я не понимаю подхода "это мне не нужно, значит это ерунда".
[quote="Хищник"]mOleg писал(а): то есть случае, когда прерывается выполнение потока по таймеру в произвольные моменты времени и все потоки процесса разделяют основные блоки кода и данных
Зачем создавать проблему, которую потом нужно будет доблестно преодолевать? Совместное использование кода и данных является источником проблем? "Не используйте код и данные совместно".[/quote]
проблема уже есть, нельзя сказать, что она носит принципиальный характер, и ее разрешение ужастно необходимо.
в конце концов и компьютер нужен не всегда - часто хватает калькулятора и пищущей машинки ;)
|
|
|
|
Добавлено: Чт мар 11, 2010 15:57 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
_Harry писал(а): С чего это она подразумевается. Подразумевается, что функциональность системы не зависит от того, какой из потоков исполняется. _Harry писал(а): Почему нельзя сделать компиляцию исключительно в главном потоке форт системы. это тоже вариант Только этот вариант не слишком ээ удобен (собственно, каким образом можно ограничить функциональность для других потоков?) Я имею ввиду, что он не проще добавления мьютекс-синхронизации. кроме того, мы в любом случае имеем вариант механизма транзакций: определение должно быть добавлено целиком, либо не должно вообще пристутсвовать в словаре. Т.е. в случае ошибки во время сборки определения состояние словаря всеравно должно быть восстановлено предыдущее, память с мусором должна быть освобождена, иначе устойчивая система просто не получится (придется в случае каждой ошибки ее перегружать либо мириться с мусором в словарях и памяти). А вообще тразнакции в своеобразном виде форт поддерживал достаточно давно, можно вспомнить тот же forget , позволяющий удалить не нужный код. _Harry писал(а): И не надо путать компиляцию с многопоточностью вообще. лично я не путаю. Просто вопрос лишь в том, обладают ли в рамках одной системы потоки равными возможностями или нет. Нужно ли это в конкретной ситуации или нет. Ведь готовому приложении далеко не всегда вообще необходима возможность добавления новых определений. _Harry писал(а): Я все же просил отвечать конкретно о практическом смысле сего изобретения. Я его не вижу (честное слово) _Harry писал(а): Понятно что для обработки асинхронных событий многопоточность нужна. Но причем здесь компиляция???????
вообще, уже сама многопоточность нужна далеко не всегда и не всем
те же асинхронные события могут обрабатываться достаточно сложным образом, и поведение этих обработчиков будет меняться во времени согласно добавляемым правилам (которые могут добавлять и сами события).
[quote="_Harry"]С чего это она подразумевается.[/quote] Подразумевается, что функциональность системы не зависит от того, какой из потоков исполняется.
[quote="_Harry"]Почему нельзя сделать компиляцию исключительно в главном потоке форт системы.[/quote] это тоже вариант :D Только этот вариант не слишком ээ удобен (собственно, каким образом можно ограничить функциональность для других потоков?) Я имею ввиду, что он не проще добавления мьютекс-синхронизации. кроме того, мы в любом случае имеем вариант механизма транзакций: определение должно быть добавлено целиком, либо не должно вообще пристутсвовать в словаре. Т.е. в случае ошибки во время сборки определения состояние словаря всеравно должно быть восстановлено предыдущее, память с мусором должна быть освобождена, иначе устойчивая система просто не получится (придется в случае каждой ошибки ее перегружать либо мириться с мусором в словарях и памяти). А вообще тразнакции в своеобразном виде форт поддерживал достаточно давно, можно вспомнить тот же forget , позволяющий удалить не нужный код.
[quote="_Harry"]И не надо путать компиляцию с многопоточностью вообще.[/quote] лично я не путаю. Просто вопрос лишь в том, обладают ли в рамках одной системы потоки равными возможностями или нет. Нужно ли это в конкретной ситуации или нет. Ведь готовому приложении далеко не всегда вообще необходима возможность добавления новых определений.
[quote="_Harry"]Я все же просил отвечать конкретно о практическом смысле сего изобретения. Я его не вижу (честное слово)[/quote] [quote="_Harry"]Понятно что для обработки асинхронных событий многопоточность нужна. Но причем здесь компиляция???????[/quote]
вообще, уже сама многопоточность нужна далеко не всегда и не всем ;)
те же асинхронные события могут обрабатываться достаточно сложным образом, и поведение этих обработчиков будет меняться во времени согласно добавляемым правилам (которые могут добавлять и сами события).
|
|
|
|
Добавлено: Чт мар 11, 2010 15:42 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): а "распределять" задачу сборки одного определения по нескольким потокам, ну как бы несколько эксцентрично Дело в том, что именно эта эксцентричность и видится за предложенным термином mOleg писал(а): Хищник писал(а): Начнем тогда уж с того, что подобные переменные должны иметь копию для каждого потока, а то ведь можно и к STATE предъявить аналогичные претензии и сказать, что она не может быть глобальной, иначе каждый поток ее дернет в свою сторону.
"ээ, дарагой!" не надо все-таки путать переменные типа BASE STATE c DP - у них разная природа. DP (т.е. HERE) глобален для всех потоков (обычно) и USER переменной его не сделаешь. А можно показать пальцем на то место, где я хоть раз упоминал DP? mOleg писал(а): тут ведь по правилам надо рассмотреть все возможные типы многозадачности и все варианты организации памяти систем. По каким правилам, интересно? Форт - это ведь не язык, основным назначением которого является организация многозадачной/многопоточной работы. Если бы у него было так записано в "программном манифесте", то вот тогда и можно было бы рассматривать все внутренние механизмы через призму того, как оно ложится на любую разновидность многопоточности. А тут получается наоборот - у Форта уже есть некоторые базовые подходы, и теперь уже проблема программиста - увязать их с теми технологиями, которые ему хочется добавить в систему. mOleg писал(а): то есть случае, когда прерывается выполнение потока по таймеру в произвольные моменты времени и все потоки процесса разделяют основные блоки кода и данных
Зачем создавать проблему, которую потом нужно будет доблестно преодолевать? Совместное использование кода и данных является источником проблем? "Не используйте код и данные совместно".
[quote="mOleg"]а "распределять" задачу сборки одного определения по нескольким потокам, ну как бы несколько эксцентрично [/quote] Дело в том, что именно эта эксцентричность и видится за предложенным термином :) [quote="mOleg"]Хищник писал(а): Начнем тогда уж с того, что подобные переменные должны иметь копию для каждого потока, а то ведь можно и к STATE предъявить аналогичные претензии и сказать, что она не может быть глобальной, иначе каждый поток ее дернет в свою сторону.
"ээ, дарагой!" не надо все-таки путать переменные типа BASE STATE c DP - у них разная природа. DP (т.е. HERE) глобален для всех потоков (обычно) и USER переменной его не сделаешь. [/quote] :shock: А можно показать пальцем на то место, где я хоть раз упоминал DP? [quote="mOleg"]тут ведь по правилам надо рассмотреть все возможные типы многозадачности и все варианты организации памяти систем.[/quote] По каким правилам, интересно? Форт - это ведь не язык, основным назначением которого является организация многозадачной/многопоточной работы. Если бы у него было так записано в "программном манифесте", то вот тогда и можно было бы рассматривать все внутренние механизмы через призму того, как оно ложится на любую разновидность многопоточности. А тут получается наоборот - у Форта уже есть некоторые базовые подходы, и теперь уже проблема программиста - увязать их с теми технологиями, которые ему хочется добавить в систему. [quote="mOleg"]то есть случае, когда прерывается выполнение потока по таймеру в произвольные моменты времени и все потоки процесса разделяют основные блоки кода и данных[/quote]
Зачем создавать проблему, которую потом нужно будет доблестно преодолевать? Совместное использование кода и данных является источником проблем? "Не используйте код и данные совместно".
|
|
|
|
Добавлено: Чт мар 11, 2010 15:31 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): Если есть многопоточная система, то многопоточная компиляция сама собой подразумевается. а так везде, где есть многопоточность и трансляция текста, может использоваться компиляция.
С чего это она подразумевается. Почему нельзя сделать компиляцию исключительно в главном потоке форт системы.
Я все же просил отвечать конкретно о практическом смысле сего изоретения. Я его не вижу (честное слово)
И не надо путать компиляцию с многопоточностью вообще. Понятно что для обработки асинхронных событий
многопоточность нужна. Но причем здесь компиляция???????
[quote="mOleg"]Если есть многопоточная система, то многопоточная компиляция сама собой подразумевается. а так везде, где есть многопоточность и трансляция текста, может использоваться компиляция. [/quote]
С чего это она подразумевается. Почему нельзя сделать компиляцию исключительно в главном потоке форт системы.
Я все же просил отвечать конкретно о практическом смысле сего изоретения. Я его не вижу :shock: (честное слово)
И не надо путать компиляцию с многопоточностью вообще. Понятно что для обработки асинхронных событий
многопоточность нужна. Но причем здесь компиляция???????
|
|
|
|
Добавлено: Чт мар 11, 2010 15:16 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): Читая словосочетание "многопоточная компиляция", создается впечатление, что речь идет о компиляции, которая специально раздается на несколько потоков. да, возможно термин не слишком удачно подобран. Речь идет о том, что несколько потоков одновременно создают код в одном и том же пространстве данных\кода. Хищник писал(а): А это все же неочевидно, если упирать на "проблемы при многопоточной компиляции". можно предложить ваш вариант названия. а "распределять" задачу сборки одного определения по нескольким потокам, ну как бы несколько эксцентрично Хищник писал(а): А почему же тогда проблемы с BASE выделяются отдельной строкой? BASE вообще в другой теме, вопросы лучше туда. Хищник писал(а): Начнем тогда уж с того, что подобные переменные должны иметь копию для каждого потока, а то ведь можно и к STATE предъявить аналогичные претензии и сказать, что она не может быть глобальной, иначе каждый поток ее дернет в свою сторону. "ээ, дарагой!" не надо все-таки путать переменные типа BASE STATE c DP - у них разная природа. DP (т.е. HERE) глобален для всех потоков (обычно) и USER переменной его не сделаешь. Хищник писал(а): А вообще можно вспомнить, что многопоточность в виде переключения адресного интерпретатора рассматривалась еще у Баранова в качестве дешевой альтернативы многозадачности.
тут ведь по правилам надо рассмотреть все возможные типы многозадачности и все варианты организации памяти систем.
Проблемы синхронизации процессов при "кольцевой многопоточности" (ROUND-ROBIN), описанной у Баранова и используемой во многих Форт-системах не так остры (хотя никуда и не уходят), чем в, ну давайте назовем, виндошной многопоточности (то есть случае, когда прерывается выполнение потока по таймеру в произвольные моменты времени и все потоки процесса разделяют основные блоки кода и данных). Так же, если вспомнить как устроена многозадачность в unix и подобных системах, можно убедиться, что возникают уже другие проблемы, в то время как проблем с DP вообще не будет(т.к. адресные пространства у "форкнутых" потоков не будут пересекаться).
[quote="Хищник"]Читая словосочетание "многопоточная компиляция", создается впечатление, что речь идет о компиляции, которая специально раздается на несколько потоков.[/quote] да, возможно термин не слишком удачно подобран. Речь идет о том, что несколько потоков одновременно создают код в одном и том же пространстве данных\кода. [quote="Хищник"] А это все же неочевидно, если упирать на "проблемы при многопоточной компиляции".[/quote] можно предложить ваш вариант названия. а "распределять" задачу сборки одного определения по нескольким потокам, ну как бы несколько эксцентрично ;)
[quote="Хищник"]А почему же тогда проблемы с BASE выделяются отдельной строкой?[/quote] BASE вообще в другой теме, вопросы лучше туда.
[quote="Хищник"]Начнем тогда уж с того, что подобные переменные должны иметь копию для каждого потока, а то ведь можно и к STATE предъявить аналогичные претензии и сказать, что она не может быть глобальной, иначе каждый поток ее дернет в свою сторону.[/quote] "ээ, дарагой!" не надо все-таки путать переменные типа BASE STATE c DP - у них разная природа. DP (т.е. HERE) глобален для всех потоков (обычно) и USER переменной его не сделаешь.
[quote="Хищник"]А вообще можно вспомнить, что многопоточность в виде переключения адресного интерпретатора рассматривалась еще у Баранова в качестве дешевой альтернативы многозадачности.[/quote]
тут ведь по правилам надо рассмотреть все возможные типы многозадачности и все варианты организации памяти систем.
Проблемы синхронизации процессов при "кольцевой многопоточности" (ROUND-ROBIN), описанной у Баранова и используемой во многих Форт-системах не так остры (хотя никуда и не уходят), чем в, ну давайте назовем, виндошной многопоточности (то есть случае, когда прерывается выполнение потока по таймеру в произвольные моменты времени и все потоки процесса разделяют основные блоки кода и данных). Так же, если вспомнить как устроена многозадачность в unix и подобных системах, можно убедиться, что возникают уже другие проблемы, в то время как проблем с DP вообще не будет(т.к. адресные пространства у "форкнутых" потоков не будут пересекаться).
|
|
|
|
Добавлено: Чт мар 11, 2010 14:11 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): _Harry писал(а): Пожалуйста объясните мне бесталковому зачем все таки нужна многопоточная компиляция.
Если есть многопоточная система, то многопоточная компиляция сама собой подразумевается. а так везде, где есть многопоточность и трансляция текста, может использоваться компиляция. Читая словосочетание "многопоточная компиляция", создается впечатление, что речь идет о компиляции, которая специально раздается на несколько потоков. Сейчас же выяснилось, что имелась в виду ситуация, когда несколько потоков независимо друг от друга решили компилировать. А это все же неочевидно, если упирать на "проблемы при многопоточной компиляции". mOleg писал(а): на самом деле сложностей я не вижу, достаточно введения простейших объектов синхронизации (мьютексов), которые не будут позволять сразу нескольким потокам создавать определения (так сделано в форке). Есть и более "продвинутые" варианты, но их уже делать только при серьезной необходимости.
А почему же тогда проблемы с BASE выделяются отдельной строкой? Начнем тогда уж с того, что подобные переменные должны иметь копию для каждого потока, а то ведь можно и к STATE предъявить аналогичные претензии и сказать, что она не может быть глобальной, иначе каждый поток ее дернет в свою сторону. А вообще можно вспомнить, что многопоточность в виде переключения адресного интерпретатора рассматривалась еще у Баранова в качестве дешевой альтернативы многозадачности. Спрашивается, чем хуже многозадачность, в свете того, что надо прилагать такие усилия для обеспечения безглючности потоков?
[quote="mOleg"]_Harry писал(а): Пожалуйста объясните мне бесталковому зачем все таки нужна многопоточная компиляция.
Если есть многопоточная система, то многопоточная компиляция сама собой подразумевается. а так везде, где есть многопоточность и трансляция текста, может использоваться компиляция. [/quote] Читая словосочетание "многопоточная компиляция", создается впечатление, что речь идет о компиляции, которая специально раздается на несколько потоков. Сейчас же выяснилось, что имелась в виду ситуация, когда несколько потоков независимо друг от друга решили компилировать. А это все же неочевидно, если упирать на "проблемы при многопоточной компиляции". [quote="mOleg"]на самом деле сложностей я не вижу, достаточно введения простейших объектов синхронизации (мьютексов), которые не будут позволять сразу нескольким потокам создавать определения (так сделано в форке). Есть и более "продвинутые" варианты, но их уже делать только при серьезной необходимости.[/quote]
А почему же тогда проблемы с BASE выделяются отдельной строкой? Начнем тогда уж с того, что подобные переменные должны иметь копию для каждого потока, а то ведь можно и к STATE предъявить аналогичные претензии и сказать, что она не может быть глобальной, иначе каждый поток ее дернет в свою сторону. А вообще можно вспомнить, что многопоточность в виде переключения адресного интерпретатора рассматривалась еще у Баранова в качестве дешевой альтернативы многозадачности. Спрашивается, чем хуже многозадачность, в свете того, что надо прилагать такие усилия для обеспечения безглючности потоков?
|
|
|
|
Добавлено: Чт мар 11, 2010 11:47 |
|
|
|
|