Olej

Робяты ;) ... POSIX, 1003b требует, чтобы для атрибутов потока могли быть установлены режимы решедулирования: int pthread_attr_setscope( pthread_attr_t* attr, PTHREAD_SCOPE_SYSTEM ); или int pthread_attr_setscope( pthread_attr_t* attr, PTHREAD_SCOPE_PROCESS ); - эти 2 и никаких больше: PTHREAD_SCOPE_SYSTEM (в рамках системы) и PTHREAD_SCOPE_PROCESS (в рамках заключающих потоки процессов) ... но 2-й способ ни в одной UNIX-like OS толком не реализован, а в Rationale к POSIX - выражается робкое сомнение как его можно реализовать вообще... И в Linux, как системе претендующей на POSIX OS, только более "колхозной" ;) - ничего другого быть не может, долгое время путаницу вносил механизм создания через clone, когда потоки и процессы создавались однотипно, "заказывая" им перечень атрибутов: немножко беременный / немножко не беременный ;)... Из POSIX определения уже понятно, что именно только и исключительно потоки и могут быть объектом решедулирования. И поэтому потоки просто не могут не быть объектами ядра :( ... Иллюзию путаницы здесь создаёт то, что всякий процесс, хотите вы того или нет ;), имеет как минимум 1 поток - главный, main() - вот он у вас и решедулируется под видом процесса. А процесс - это просто мёртвая статическая оболочка над потоком, служащая менеджеру процессов для занесения туда статистической и учётной информации, типа "занимаемое процессорное время"... В других ОС, например QNX или Plan9 - это гораздо отчётливее видно, в Linux это смазывается его монолитным макроядром :(.

Это в принципе неверно - многопоточность/параллельность применима к однопроцессорам не в меньшей мере, чем к много процессорам. Это - другой взгляд, и другой образ мышления, отличающийся от последовательного программирования. В этом clone и состоит беда Linux реализации. Поменялось :(. Принципиально. Начиная с 2.6 модель потоков Linux стала гораздо ближе (в своём поведении, а не сколько в виде системных вызовов) к POSIX. А до этого был совершенно уродливый конгломерат, обязанный именно clone. Посмотрите здесь: http://www.books.ru/shop/books/357604 или хотя бы здесь: http://qnxclub.net/files/articles/pthread/pthread.pdf Ага, ща-а-а-з... а до Linux была, оказывается, голая пустыня ;)... Потоки присутствуют во всех UNIX-like системах начиная с 80-Х ... ну, второй половины 80-х. И стандартизованы расширением POSIX1003.b.

А вы видели хоть одну ОС, даже далеко не RT, про которую было бы написано, что она - не лучшая в мире... Так вот, некоторое время назад (лет 7-9), была такая волна - и Windows NT стала "писаться" как RTOS ... правда с оговорками: "... ну не совсем чтоб жёсткий RT, но всё же..." ;)

Вряд ли ;)... Сама политика VindRiver построена так, чтобы не распыляться "по горизонтальным рынкам"... я как-то контактировал с ними по вопросу получения демонстрационных версий и простейших evaluation ;) - там процедура такая, даже для этого, что вы должны им выложить про себя информацию, всю подноготную ... а потом они решат ;). В принципе, при очень широком декларируемом применении в hard RT, vxWorks имеет слишком много проколов по резонансным проектам для того, чтобы позволить себе широко разбрасываться информацией... Посмотрите вот это: http://qnxclub.net/files/articles/vxtoqnx/vxtoqnx.pdf Porting Legacy Systems from WindRiver's VxWorks® to the QNX® Neutrino® RTOS - если хоть немного представлять QNX, то по этому достаточно объёмному материалу как раз можно составить представление о том "чего же нет в VxWorks и чего её не хватает".

Вот здесь: http://qnx.org.ru/index.php?option=com_min...&topic=2999 - правда здесь больше ругают ;) на 10-ти страницах форума, но есть и информация, некоторые детали, кроме того, там в разговоре "защищается" ;) кто-то из разработчиков из НИИСИ РАН...

Если упомнили всуе ;)... OpenOffice интереснее ещё и тем (и это надолго будет), что для хранения документов они выбрали с самого начала XML-формат, ... а не хрен знает что, как в MS Office, и это даёт огромные преимущества ... для программирующей публики, конечно. Пару книг своих, уже вышедших, я готовил именно в OpenOffice, хотя бы потому, что первичная подготовка текстов в нём куда комфортнее ... потом, правда, это всё трансформировалось в MS Office (так привыкли и требуют издательства), но без всяких проблем (!).

А в этом нет никакого мазохизма - об этом давно писали и Дэйкстра и Хоар (техника "мониторов Хоара", реализуемая прямо в синтаксисе некоторых языков ... да и рандеву Ada - нечто из этого сорта)... В развитии языков школы Вирта: Oberon, Zenon ... туда, куда она пошла от Pascal/Modula - это даже имеет термин "активный объект" и есть у них целой идеологией... Можете глянуть здесь, в более общем виде: http://qnxclub.net/modules.php?name=Forums...wtopic&t=64 http://qnxclub.net/modules.php?name=Forums...wtopic&t=13 А здесь в упрощённой реализации для решения частной задачи: http://qnxclub.net/modules.php?name=Forums...topic&t=315 http://qnxclub.net/modules.php?name=Forums...topic&t=317 А по поводу С++, да ещё для "низовой" ниши изделий - то это ещё вопрос... за счёт ресурсоёмкости полученного ПО (в сравнении с pure C) - его ещё нужно тщательно прорабатывать в каждом конкретном случае, прежде чем решиться.

Гляньте ещё сюда: http://forum.sources.ru/index.php?showtopic=11301 - там 10 форумных страниц: "Аналоги виндовых прог" - может чего подскажет ;). P.S. И конечно это: http://www.linuxrsp.ru/win-lin-soft/table-rus.html - 7 лет пополняемая таблица соответствий.

Я бы так и делал, и, может оказаться, не только в lite, но и в конечном варианте... Я не скажу наверняка, как это будет в Linux (я это не проверял), но в QNX - разумно распорядившись приоритетами, можно гарантировать, что время начала операции будет плавать между 2-4 ticksize ... но всё, что касается диспетчеризации, вытеснения + деталей отработки службы времени (а там всё совсем не очевидно) - это всё регламентируется моделями POSIX, а одна и другая ОС в той или иной мере пытаются следовать POSIX. Мне кажется, что при ticksize=10мс. вы должны определённо вписаться в 100мс. интервал, если обезопаситься от всех неожиданностей + разумно распорядиться приоритетами + использовать только статические приоритеты при RR диспетчеризации (это те, кторые RT - об этом хорошо растолковывается в такой книжке "Ядро LINUX с комментариями" ... или как-то так - нет под рукой). Потом результат можно легко проверить на адекватность ... и у вас ещё остаётся возможность переопределить в ядре ticksize в сторону уменьшения. P.S. в конечном счёте, если это серьёзная нужда и не лень повозиться, я готов специально найти, вырезать и выслать из книжки: http://www.books.ru/shop/books/357604 - раздельчик, где специально ставилась задача синхронизации с наименьшей дисперсией интервала, с проверкой результата (это под QNX, но GCC - может быть "в лоб" перенесено в LINUX и проверено) ... это не совсем то, но очень близкие вещи - может на что-то натолкнуть.

тайм-ауты select() выражены в той же дискретной сетке timeslice, и срабатывание наступит на следующем (а иногда и не следующем) истечении timeslice ... т.е. задачу временного разрешения это никак не меняет. P.S. кроме того, select() - это один из самых старых и мощных средств API, но именно из-за того, что старых - он принципиально not thread safe, что в новых проектах может стать ну очень серьёзным препятствием ... с select() нужно сильно осторожно ;).

... вот только в user space до этого нужно ждать (может и до бесконечности) RUNNING и доступа к этому файлу устройства:(...

А kernel module никак и не решит вашу проблему: он может уменьшить и детерминировать время латентности на прерывание, или I/O операции ... но вас ведь интересует "временная девиация" в пользовательском приложении, так?

- в стандартном варианте - 10мс., но при ядре старше 2.6.х вы можете эту дискретность уменьшить. - но вы можете просто не позволять решедулировать этот процесс user space другими, играясь приоритетом и политикой диспетчеризации, тогда дискретность вам вообще до фени (только не забыть устранить всякое "динамическое управление приоритетом" со стороны ОС): - это, в общем случае, так, но у вас, по сказанному раньше, нет особенно с фокусами ни юзеровских ни системных процессов? - неприятность в том, что кроме штатного решедулирования вам большую (во много раз) дисперсию могут "подарить" другие механизмы: возникновение свопинга (который должен быть напрочь исключён), ... инверсия приоритетов, которую можно создать уже при 3-х процессах/потоках... Смотрите и в эту сторону. P.S. а вообще, именно из-за этого, что механизмы никакого Linux не гарантируют невозникновение каких-то задержек на все-все 100% - это заложено в идеологии системы - Linux ни с какими приставками RT не будет до конца RT (даже при 2-х ядерности)... Хотя у некоторых здесь бытует мнение, что всякое RT - это некий мистификасьён ;) ... - может они что-то знают, и будем им верить? ;)

Для начала: http://qnxclub.net/modules.php?name=Forums...viewtopic&t=192 - там есть координаты откуда получить дитрибутив и т.д.

Простейшее решение: берклиевский пакетный фильтр - BPF, есть в составе QNX 6.3: nfm-bpf.so (монтируется к io-net) ... пользование BPF см. Р.Стивенс "Разработка сетевых приложений", С.-П. "Питер" ... да и в других многих местах. Далее - tcpdump (который и использует BPF)... Наконец, если уж совсем глубоко копать: напишите свой модуль (фильтра) к io-net ... в принципе, в техдокументации + DDK QNX информации достаточно ... только раскидана она ... Участник форума qnx.org.ru MikeP как-то написал большой раздел для возможной будущей книги (собирались мы издать, но соберёмся ли - не знаю ;)...) о написании модулей io-net, с примерами, более чем достаточно... обратитесь к ниму, или, на худой конец, я могу прислать текст, но согласовав сначала с MikeP - это его материал... Но это - тяжёлый путь, и ним следует пользоваться только когда проще - никак. P.S. (позже): свяжитесь со мной - я вас "выведу" ;) на этот материал ... вопрос решён.

"... и тут пришёл поручик Ржевский, и всё опошлил..."(с). Мне аж неудобно и грустно как-то становится, что не могу присоединится к такому жизнеутверждающему "одобрям-с" относительно Windows для ответственных приложений ... (не важно какой он XP etc. ... после Win32 Windows NT 4 - ничего принципиально в этом направлении не прибавилось), ... особенно обратите внимание на http://old.osp.ru/win2000/2006/01/084_t1.htm такое жеманное: но всё гораздо хуже ;): http://athena.vvsu.ru/carina/RealTime/Realtime_3.html http://www.nautsilus.ru/products/winnt.htm http://www.pcweek.ru/?ID=60308 http://www.rtsoft.ru/article/home_md.html?p=600308

Тема давняя, но вот попался на глаза снова URL: http://www.onesmartclick.com/rtos/rtos.html - там есть огромным списком перечисление RTOS со ссылками, часть из них free или эксперименты... Выбирай на вкус ;).

насчет strdup, "я такой умный вещь скажу, ты только не обижайся"(с): в алгоритмах управления strdup-ы не встречаются. Ни к чему они там. Круто! А i++ - встречаются ? а ++i ? Теперь осталось только проделать ревизию "встречаются" / "не встречаются" - и оформить ... "руководящим и направляющим" документом, обязательным к исполнению ;) ... что-то мне это мучительно напомнило ... а, вот оно (прошу прощения за длинную off-topic цитату) http://qnx.org.ru/viewpagedthread7n4227n4.html :

Есть ;). Только вот в чём дело, когда вы выполняете операцию с адресуемой в RAM областью, типа оператора: int i; i = 0; - то в зависимости от того, попадает она в кэш или нет, вы имеете разницу во времени операции отличающуюся в лучшем случае в 2-3 раза (я реально это смотрел), и операцию (если x86) на 5-8 машинных тактов (десяток-другой нсек.), если вы последовательно выполняете операции над наукад 1000 переменными, скажем, если очень грубо считать что 50% их попадает в кэш, а 50% - нет, то разброс у вас (по сравнению с оптимумом) будет 1.5-2 раза. Физческие операции загрузки-выгрузки на диск - на 2-3 порядка медленнее... Но и это не самое худшее, когда вы выполняете ту же операцию, которую я выписал выше, и i находится на выгруженной странице, то загрузка-выгрузка производится страницами RAM, в x86 - 4K "туда" + 4К "обратно" - вот вам ещё 1 порядок непредсказуемости на времени тривиальной операции - до 4-х порядков. Неопределённость (дисперсия) времён 50-100% - это одно, а 4 порядка - это, согласитесь, несколько другое... Это не я придумал ;), и именно из подобных соображений на кэширование и другие подобные "ускорители" (те же спекулятивные вычисление, опережающее конвейерное выполнение etc.) смотрят в обсуждениях и публикациях об РВ "сквозь пальцы", а такие возможности как виртуализация страниц RAM - отвергаются категорически. "Медленнее/быстрее" - вообще к РВ не имеет касательства, общепризнанно и с этим уже, кажется, смирились ;), что система (ОС или целевая система вообще), удовлетворяющая требованиям РВ будет, при прочих равных, несколько медленнее, чем аналогичная, к которой такие требования не предъявлялись (GPOS, например). А вот то, что "зато система живет, а не рушится" ... это достаточно сомнительное достоинство в системах, требующих критической по времени реакции ... Goroshko Egor затронул это... Ну представьте, к примеру, РЛС системы ПВО/ПРО, как одну из систем РВ ... в чём разница между тем, что она пропустит отметку цели, или обнаружит её с сильно превышенным подлётным временем? Разве только в том, что в 1-м случае система "накроется" в полностью благодушном неведении, а во 2-м - в стоп-кадре "паническое разбегание персонала кто-куда"... "Жизнь становится лучше, товарищи. Жизнь становится веселее"(с) - автор известен... Ничего страшного в том, что "Виндовоз становится все надежнее и надежнее", конечно, нет ... несколько настораживает, правда, то, что он "становится надежнее" уже порядка 20-ти лет, и ... "завтра вот-вот ...". А, в принципе, Виндовоз - хорошая офисная система ... каждая вещь разрабатывается под свои техусловия ... мне только совершенно непонятно желание обязательно притулить не делавшуюся для этого вещь "на все случаи жизни"... как-то малоуместно пытаться ездить на "Шевроле" по пахоте, ровно так же, как БТР странно смотрится перед "навороченным" офисом в центре города... Конечно не надо ;) - если бы это было время реакции, время ответа ... и т.д. - но это единица шкалы, неточность определения, а минимальные разрешимые интервалы будут в несколько раз больше единицы шкалы ... а это уже "не не надо" ;). Есть и такая точка зрения ... только она тоже не "строго определённая" - отмечается, что и такой компонент есть в терминологии "РВ" ;)... Почему же нет? Есть - безупречная success story более 25-лет - всегда безотказной работы, годами в необслуживаемом режиме... (это 25 лет - ~ столько, сколько вся история MS DOS + Windows с уговорами, что "завтра будет лучше чем вчера"). Хорошее определение ... только "масло маслянное": а что, в IBM 360 60-х годов - порядок обработки информации не предопределялся ходом процессов вне ЭВМ? начиная с того, как пользователь вложил коложу перфокарт?, и как он правильно их вложил? ... и до того места, провернулся ли уже барабан АЦПУ до положения, когда следует печатать следующую строчку "простыни"? ... Да пожалуйста ... описывайте. Кто ж возбраняет? Только, по возможности, воздержитесь от непреодолимого желания его продавать как "средства описания режимов работы в реальном масштабе времени" - тем, кому может прийти в голову начать описывать такие режимы ;)... 1. - Так выпьем же за то, что грузины лучше чем армяне... - Ну чем, чем лучше? - ... чем армяне. (с). С "более прозрачен" для тех, кто не знает С++, так же как и наоборот. 2. "операции с тем же ОЗУ" ... ? (я не заню какое это "то же" ОЗУ - это С & C++ работают с одним и тем же ОЗУ ;)) ... наверное имелись в виду динамические операции? - так их "плотность" определяется желаниями пишущего использовать или не использовать, а не то, на чём он выражает свои желания... А кстати - как на счёт strdup()? ;) - многие ли задумываются что они при этом делают? А если так ;) : void func( char* S1 ) { char* S2 = S1; ... return( strdup( S2) ); }; 3. где она - эта статистика? и уровень её адекватности? - URL в студию! P.S. сравнивать С/С++ по критерию "плотности ошибок" вообще неблагодарное занятие - слишком близкие эти 2 клона, и оба предрпсположенные к ошибкам... а хотите принципиально другую защищённость от ошибок - учите Ada ;)! Ну ладно ... Повеселились, покуражились - и будя!

А вообще то, разговор уехал несколько в сторону от заданной теме, и теперь он должен был бы называться: "Какая РТОС мне бы нужна, когда она мне не нужна". ;)

Вот когда истины прописные, то это часто и есть побудительный мотив иногда в них засомневаться ;)... я совершенно не согласен с утверждением на все случаи жизни, что динамическое управление памятью - такое уж принципиальное зло там где РВ. Во-первых, многое зависит от базового механизма распределения, который использует конкретная ОС - я уже обращал внимание: посмотрите на pSOS, как там управляется память (а pSOS одна из лучше зарекомендовавших себя РТОС). Во-вторых, и в С и в С++ вы можете (но совершенно разным способом) реализовать своё управление памятью, которое будет оптимально для этого класса задач... В-третьих, обращу внимание на деталь, которую часто упускают из виду: - динамическое распределение С - malloc()/free() - использует память heap; - динамическое распределение С++ - new()/delete - использует (по стандарту) совершенно другой класс памяти - "динамически распределяемая", который в реализации многих ОС совпадает с heap, но это совершенно не обязательно... - таким образом, у вас есть и 2 механизма, надстроенных один над другим - надстройте и наворотите над ними всё что угодно... ... вот так, если достаточно грубо описывать процесс. Ну, это было бы слишком просто ;) - но может закончиться тем, что при наличиии дофига освобождённой (но ещё не деаллокированной на низком приоритете) памяти, высокоприоритетный аллокатор уже не сможет ничего добыть... Кроме того, "ручное" управление памятью в стиле С/С++ (malloc()/free(), new()/delete), которое тоже требует аллокаторов/деаллокаторов, и автоматическая сборка "неиспользуемого мусора", основанная на признаках неиспользуемости (напр., счётчике ссылок, но не только) - это очень разные по сложности механизмы. Но при всём том, то, что используемые по умолчанию в ОС механизмы управления памятью не обладают ... нужными качествами, или не реализованы (или не известны широко) системы сборки мусора в ссылочных языках - это ещё вовсе не есть окончательный аргумент того, что динамические механизмы так уж неприемлемы в РВ. Со словом "надёжность" к ПО нужно подходить с большой тщательностью - в ПО нет стареющих или изнашивающихся частей, чтобы к нему можно было применять положения теории надёжности. Но в нём всегда есть скрытые ошибки, которые и выявляются как "не надёжность"... Теперь смотрите сюда ;) : - С является подмножеством С++, программа С будет всегда (ну, почти всегда ;), на 99.999%) синтаксически совместима с С++ (несовместимости - описаны, они все - из разряда казусов, и могут быть устранены)... - программу, написанную на чистом С вы можете компилировать командой: "gcc ...", но её же и командой "g++ ..." - в режиме синтаксических правил С++... - будет та же программа, скомпилированная во втором случае - надёжнее 1-й? (т.е. в смысле - содержать меньше скрытых ошибок). Будет! - по очень простой причине: гораздо более строгий типизированный контроль ... того же исходного кода (я иногда развлекаюсь так, компилируя pure C в режиме C++). - это относительно одного и того же файла кода... т.е. того же подмножества языка, которое общее... - будет ли "безошибочнее" надмножество, которое выводит С++ за пределы С ... а безошибочнее чего? с чем вы собираетесь сравнивать, если эквивалента нет? Я нигде не говорил, что "надежность Си++ выше всего", я говорил: надёжности С++ при прочих равных не с чего быть ниже, чем С. И только. А все "статистические, так и теоретические данные" ... смотрел я иногда - это всё из области спекуляций. Владимир, а). "т.н. РТ-сообщество" ;) и QNX-сообщество - это далеко не одно и то же - 1-е намного шире 2-го; б). нет как такового и "QNX-сообщества" - есть совершенно разрознённые, хотя их и достаточно много уже, специалисты, практически работающие с QNX ... с гораздо большими основаниями можно было бы говорить об Linux-сообществе, FreeBSD-сообществе, MAC-сообществе ... там это хоть "клуб по интересам" напоминает ;)... Так что пусть это вас так сильно не пугает ;) - вам никто не угрожает.

Естественно и socket тоже - как механизм/абстракция реализации соединения в пространстве имён UNIX домена.

так чего же он тогда RedHat 4.0? как-то мне помниться 9.0 был... да, неважно. давно я с Linux не возился... помнится там есть ещё hosts.deny (или как-то так): один - список разрешённых, другой - запрещённых... чуть позже пойду посмотрю в QNX. не помню, но точно есть... только не по "native" нужно искать, а по техдокументации ;)

я не помню, что такое конкретно NXserver/NXclient. вот такое старое? :( нечто такое было в ALT Linux, и было это связано с правами доступа (или с флагами доступа к файлам), пройдитесь по ним, кроме того, было когда именно в Х определялась работа через native UNIX domain, а не серез TCP/IP (естественно, UNIX domain за пределы локального хоста ... "не тянет" ;) ).

Абсолютно верно, но это уже другая песня: NAT нужен только в том случае, если IP локальной сети используют "локальные" группы IP (10.* , 172.16-32.*, 192.168.*), что почти всегда и бывает. Но это уже - вопрос выхода "вовне" шлюзового хоста, из вопроса: - можно предположить ;), что автор уже с "мой девайс" коннект уже настроил.