Средства и методы разработки

Некоторый выводы из обсуждения здесь на и на электрониксе. Ситуация с памятию следующая. Разговаривал я тут по душам с разработчкиком одного телематического сервака. Который принимает данные от 1к+ GSM девайсиков. Первое действие его сервера при запуске - отожрать у ОСи кучу памяти (задается) и запустить поток собственного менеджера памяти Видимо, ситуация по памяти выглядит так: * при инициализации проиходит обращение к malloc * при норамальной работе задача (задачи) сами занимаются управлением собственной памятью (ОСь не обладает телепатическими способностями, чтобы понять, как и когда можно дефрагментировать память конкретного приложения) * free вызывается только при глобальном завершении процесса на Сервере или типа когда контроллер сдох Что касается Switch-технологий. Есть алгоритм решения задачи. Он живет сам по себе. Есть способы реализации этого алгоритма: структурное, функциональное, логическое, и еще 1001 программирование. Есть железяка, которая, на самом деле, понимает только один язык - машинные коды. И вопрос только в том, как корректно преобразовать алгоритм в машинные коды, чтобы: * машинные коды гарантированно реализовывали тот же алгорим, причем такая верификация должна быть проведена аналитически, без перебора всех состояний кода программы (для сколь-нибудь сложных программ это нереально) * они должны это гарантированно делать за заданное время. Сила "обычных" языков программировнаия в том, что они неплохо ложатся на мозги программеров. Но соотнесение их с алгоритмом не так-то просто. Давайте говорить на чистоту - пока нет способов (точнее, мне они неизвестны), формальной верификации кода на соотвествие алгоритму. Т.е. есть алгоритм, есть программа, и программер говорит - она реализует этот алгоритм. Проверяем - вроде работает. При этом никакого автоматического способа проверить, соотвествует ли программа алгоритму, нет. И никакой гарантии, что в программе предусмотрена обработка всех состояний, тоже нет. Есть паллиативы. Которые ресурсы среды исполнения разменивают на сложность программирования. Парадигма многозадачности удобная для восприятия человеком. Она позволяте разбить код на куски, и четко отследить связи между этими кусками. Что и дают все эти потоки, сигналы, семафоры, m-box, пайпы и сокеты. Язк программирования + ОСь гарантируют в таком случае изоляцию этих кусков программ. Это возволяет осуществить декомпозицию задачи. Но плата за это - расход ресурсов среды исполнения. С другой стороны, обычный С компилятор отлажен настолько, что Вы можете иметь миллионы функций, вызывать их согласнов Вашей логики, и компилятор все это отработает корректно. Вот теперь самый главный вопрос - как всю эту систему вызова "миллиона" функций сопоставить с решаемым алгоритмом? В виде написания "линейного" текста программы точно нет. Вопрос закрыт. Только в виде некоего графического представляния составных частей, графа, который нужно корретно отобразить на код. Спопобы такого отображения и есть предмет далеко не оконченных изысканий Шалыто и многих других товарищей. Общепринятого сопосба (каким в своей области стал, например, язык С) пока нет. Хотя теоретические основы вроде как есть. Вопрос - кто какие системы работы с конечными атвоматами знает - кроме iSTATE и Rapsody?