Don_Ambrosio

А размещать сообщения так.. Для информации....Разрешено только избранным? Помню когда я один раз разместил сообщение "для информации" меня сразу же забанили на месяц с формулировкой "за флуд"

А вопрос то где? Его автор так и не задал по-моему. А если это реклама то зачем? Если бы меня интересовали новые чипы от Atmel, то чтобы мне помешало заглянуть на сайт производителя? Зачем здесь-то это писать?

В каком редакторе есть подсветка не релевантных идентификаторов? Что я под этим понимаю: Допустим, есть класс и я изменил в нём некий метод. Тогда редактор должен (если я так хочу) подсветить мне все идентификаторы в программе так или иначе связанные с этим классом по причине их не релевантности. Вообще разработка и правка программы суть некоторые транзакции, которые нельзя выполнить частично. Например все внесённые изменения в программу при переход от одной идеологии работы с сетью к другой можно рассматривать как одну большую транзакцию. Хорошо бы было, чтобы редактор распознавал тип проводимой в данный момент транзакции и как-то оповещал о её незавершённости. Ведь не секрет, что большинство ошибок в программе происходят из-за того, что при сложных транзакциях редактирования программы, состоящих из многих операций редактирования в различных частях программы, программист забывает произвести некоторые операции, чтобы транзакция была завершённой. Почему транзакция может состоять из нескольких операций правки в различных частях программы? Да потому что часто бывает, что изменив что-то в одной части программы, мы просто обязаны изменить связанные с ней другие части программы. А таких связей бывает очень много. И очень трудно бывает уследить за тем, чтобы все связанные части были тоже отредактированы. И какие ещё полезные фичи есть в программистских тестовых редакторах?

Разделяемая память не годится, потому что у меня не кластер, а сеть с не полносвязной топологией с последовательной передачей инфы по достаточно протяжённым (десятки метров) каналов с достаточно низкой скоростью ( 4800 Бод) Не мой случай.. Аднозначно Да в курсе я про эти протоколы. Понятие реалтайма можно как-то связать только с QoS. И то там не слова про механизм вытеснения высокоприоритетными пакетами низкоприоритетных и про динамическую модификацию приоритетов и политику диспетчеризации пакетов (по аналогии с диспетчеризацией потоков) Не.. ТиниОС однозначно не из той оперы. Это ещё почему же? Полно задач, когда Event-ы регистрирует один узел, а обрабатываются они на совсем другом узле.

Ну т.е. такие RTOS в доках на которые чёрным по белому написано, что регламентируется время реакции на событие как и у обычных RTOS (у которых регламентируется время реакции только на "местные" событие), но независимо от того, что событие произошло на одном девайсе сети, а его поток обработчик находится на другом девайсе сети. А? Наверное там должно иметь место понятие "приоритет пакета" и "вытеснение пакета". Т.е. когда пакет с бОльшим приоритетом может вытеснить с магистрали пакет с меньшим приоритетом, аналогично тому как поток с бОльшим приоритетом вытесняет поток с меньшим приоритетом. Я прав? Если это так, то как это реализуется? Вообще где можно о них чё-нить почитать? О том как они устроены. Как обеспечивается в них регламентируемое время обработки события не смотря на то, что в системе могут быть события, требующие разного времени реакции и не смотря на то, что устройство, которое сигналит о событии и устройство получатель инфы о событии могут находится друг от друга на "расстоянии" нескольких хопов

Дык возьми датушифт на любой Атмеловский контроллер с USB и почитай. В чём проблема?

А в чём проблема-то? Озвучьте

Господа! А на вопрос так и не ответили:

Согласен. Хотя бы межуровневые интерфейсы должны быть оговорены. Ладно. Я пока возьму тайм-аут. А то опять скажу какую-нить ахинею из-за спешки, когда руки стучат по клаве быстрей мыслей :) Просто сейчас занят написанием одной софтинки и параллельно пытаюсь вести дискуссию на такую сложнейшую тему. Получается фигово :) Сначал разберусь с софтинкой, а потом на досуге подумаю как лучше Вам всё сформулировать. P.S. Насколько важно договориться по "междумордовому интерфейсу" видно даже по-нашему общению: я не понимаю, что хотите Вы до меня донести , а Вы не понимаете, чего всеже хочу я :) Прям как в программах

Себе, себе. Но даже когда я делаю себе не хочу усложнять себе жизнь. Хочу чтоб прослеживался систематический промышленный подход к софтостроительству. А потом, может кому после меня ещё придётся поддерживать этот софт. Чтоб он голову не сломал. Ужоснах :( Неужели всё так печально? А как же там запуски сотен вирутальных машин на одном компе и прочее? Ну чтоб отладить стек сетевых протоколов. Первый уровень - прикладная не распределённая софтина Второй уровеь - Софт распаралеливания прикладной софтины и раскидывания её частей по процессорам. Сюда же стек сетевых протоколов. Т.е. все это скрывает от приложения факт наличия сети. Третий уровень - имитация наличия сети для второго уровня. Т.е. всё это скрывает от сетевых протоколов факт отсутствия сети, что всё гоняется на одной физической машине Да не силён я в терминологии. Признаю

Не согласен. Хочу всё-же упростить себе любимому жизнь сделав по возможности все уровни этой модели незавимыми от реализации других уровней. Т.е. я хочу сделать, чтобы каждому уровню модели было "глубоко фиолетово" от того, как конкретно реализованы другие уровни, единтсвенное что должен знать один уровень о другом - его интерфейс. И даже его знать не надо. Например приложение вообще не должно знать ничего о том, каким образом его распаралелят и то на одном процессоре оно будет выполняться или на нескольких. Т.е. програмер , вишущий прикладной уровень может вообще не загружать себя тем, как там устроены нижние уровни А программер, пишущий стек сетевых протоколов и код, который дробит и раскидывает код приложения по другим процессорам сети, может не загружать себя тем, что реально код его распределённых процедур работает не на разных девайсах, а на одном. Ибо это "головная боль" не его, а программера, пишущего софтовый симулятор сети . Ну и т.д.

Не совсем так. Да, для приложения надо имитировать, что оно работает на одном процессоре. Но ОДНОВРЕМЕННО для средств распаралливания и стеков сетевых протоколов нужно иммитировать, что имеется несколько узлов и они работают не них

А как быть с реализацией отладки распределёных сетевых приложений и стеков сетевых протоколов не имея всей сети, на которой они будут работать, а имея в распоряжении один единственный процессор? Т.к. как софтово имитировать сеть для таких сетевых распределённых приложений? Чтобы части приложений даже предположить не смогли, что они работают не на разных узлах локальной сети, а в одном единственном процессоре. Хотя у меня задача даже ещё сложней : Не распределённое приложение СКРЫТЫМ для него образом будет параллельно работать на нескольких узлах сети (т.е.приложение не должно даже "догадываться" о том, что оно выполняется не на одном, а на нескольких процессорах сети). А сеть я хочу софтово имитировать на одном процессоре. Т.е. получается два уровня абстракции и 4 уровня отладки: - отладка самого целевого не распределённого приложения - отладка средств его распараллеливания и распределения по узлам сети - отладка стеков сетевых протоколов сети на одном процессоре - отладка средств скрытия от кода сетевых протоколов того, что они реально выполняются на одном процессоре, а не на нескольких

Использовали ли Вы при программировании абстракцию сети кроме задач построения локальных сетей? Т.е. где удобно использовать абстракцию сети/графа при работе с программными объектами. Т.е. организовать программу как локальную сеть: передаём «пакет» одному объекту, тот анализирует «пакет» и если он предназначен не ему - передаёт другому, И так далее. Т.е. происходит определение «маршрута» и следование «пакета» по этому «маршруту», хотя объекты (т.е. экземпляры класса) находятся в ОЗУ единственного процессора и можно было бы передать «пакет» сразу напрямую нужному объекту. В каких случаях используется такая многоступенчатость вместо передачи «напрямую»? Ведь по сути, объект (экземпляр класса, существующий в памяти) можно рассматривать как узел локальной сети, и наоборот, узел локальной сети можно рассматривать как некий программный объект если абстрагироваться от несущественных различий. Добавлю, чтобы в программе был код маршрутизатора, который определяет маршрут до "узла", а также динамическое подключение/отключение "узлов"(поввторю: где под "узлами сети" я понимаю экземпляры класса, находящиеся в памяти одного единственного процессора). P.S. Хочу разработать сетевую RTOS, в которой реализовать прозрачность работы с потоками и экземплярами класса. Т.е. для юзверя было глубоко "фиолетово" где находится поток или экземпляр класса: на том же самом процессоре или вообще где-то на другом узле локальной сети на удалении 10-ти хопов. Чтобы он работал с ними однообразно Добавлю, чтобы в программе был код маршрутизатора, который определяет маршрут до "узла", а также динамическое подключение/отключение "узлов"(поввторю: где под "узлами сети" я понимаю экземпляры класса, находящиеся в памяти одного единственного процессора). P.S. Хочу разработать сетевую RTOS, в которой реализовать прозрачность работы с потоками и экземплярами класса. Т.е. для юзверя было глубоко "фиолетово" где находится поток или экземпляр класса: на том же самом процессоре или вообще где-то на другом узле локальной сети на удалении 10-ти хопов. Чтобы он работал с ними однообразно Добавление от 29.06.2008 11:53: А вообще задача состоит в том, чтобы абстрагироваться от существования отдельных процессоров, от существования графа связей, от того, что вообще говоря есть хопы, а писать код верхнего уровня абстракции так, как будто всё находится в памяти единственного процессор Или наоборот. Абстрагироваться от существоания одного процессора, и решать задачу так, как будто есть целая сеть процессоров Зачем это нужно? Да чтоб отлаживать сеть симулируя её на одном единственном процессоре. Т.е. софт верхнего уровня, чтоб даже не предполагал, что никакой сети нет, и всё "действо" происходит на одном единственном процессоре И наоборот, чтобы использовать софт, который работает только с одним процессором, и чтобы он даже не предполагал, что его код выполняется параллельно на 155-ти процессорах

Да ужжж.. Задача, как я и предполагал, не такая простая, как многим кажется