„только вот эффективно это будет лишь в ядре без сбросов TLB. иначе проц будет только и делать что стоять ожидая пока страница будет в TLB. “

Возможно. Но в этом случае - это вопрос уже реализации, а не абстракции.

Narkomanius
„щас я буду издеваться :)“

Ну и что? Написав пол кило абсолютного бреда Вы ожидаете, что это доставит посетителям Форума пользу или удовольствие?

Не умеете ГРАМОТНО предираться - ЛУЧШЕ молчите!

Воть.
Похоже с покупкой Таненбаума и других полезных книг я ухожу в поиск и врятли в ближайшее время что-то буду здесь постить. Такова судьба...=))
Хотя в ближайшее время(пара недель) постараюсь общественности в рамках проекта "полёт валькирии" представить прототип одной из частей компилятора URAN, а имено, ответственную за низкоуровневую оптимизацию на ген алгоритмах...=)

татенбаум наделал макулатуры на 1037 листов. эта книга полезна сама по себе не будет - она только упорядочивает мысли, он идей не даёт. у мя на полке щас книжек на 3 татенбаума не считая распечаток с инета. 14 меяцев доводил идею операционки, чтоб без тормозов в любом месте, надежно и быстро было( у мя такая задача минимум - скорость + нет глюков + все просто до предела + мало требует + можно запускать трояны вири без вреда системе(это я еще не проработал, рано))

Edmond - ты бред написал. модно что ли щас стало - все в ООП загонять? сперва пусть все будет объекты, инкапсуляция пусть будет потому что красиво звучит, наследование и интерфейсы. а остальное авось приложится, если вы товарисч серьёзно считаете что ООП - самоцель любой системы, то идите на 3os.ru там фанатики вам расскажут больше умных слов - и про фабрику классов, и про таблицу кроссметодов. короче много невого и полезного. вообще у них там идеальный пример как не надо делать ось.

2 Narkomanius, сорри, что всё же пишу сюда... Но зря ты так про Таненбаума... просто у тебя наверно первое издание, а оно(если мне память не изменяет) 90-91 гг. А я тут купил второе - там много нового и переработанного и книга больше стала. А вот насчёт 3OS.ru я полностью с тобой согласен!=)))

„Edmond - ты бред написал.“

Ну коннееечно. Я бред написал, Таненбаум вообще бред один пишет на кучу страниц. И все - только одиин бред и пишут :)))))))
Да я вообще не спорю - что мы понимаем в проектировании сложных систем. Ничего :))

Narkomanius
„модно что ли щас стало - все в ООП загонять?“

Уверен, что Вы сами - вообще не понимаете что такое ООП.
Что собственно некоторым товарищам доставляет удовольствие спорить в той области в которой они ничего не смыслят.

Я хочу, чтобы на этот ответ обратили внимание все, кто пишит в подобные тапики про ОС.

Дело в том, что список который был приведен мною, и в котором действиетльно в 1 пункте стоит дописать про связи между объектами - ООП совершенно не причём.

Посмотрите внимательно - где там слово ООП?
Это Narkomanius
туда его приплёл. А не я.

Далее.

Термин интерфейс, объект, наследование - напрямую никак не ПРИВЯЗАН с ООП.

Термин инкапсуляция - опять таки не пренадлежит ООП, это более общий термин, означающий разделение информации в системах и подсистемах.

Если бы вы Знали это - то не написали бы такого.

Единственно что, слово "наследование" могло бы претендовать на ссылку в ООП технологию. Но снова таки - разве только в ООП она имеет смысл.

Приведённые мною пункты касались скорее ядерно-поточной модели, хотя явно я про это не написал.

В отличие от ООП сервер-ядерно-поточная модель обладает куда более лучшими свойствами расширяемости и переносимости.

Реализация STREAMS может быть рассмотрена как пример такой модели.

=========================================

Теперь пару слов о птичках.

Чтобы иметь право говорить о Таненбаумах и etc.
Следует как минимум достичь его уровня понимания технологий и приёмов о которых он пишет.

Обычно отличают 2 уровня в понимание
1. Естественное
2. Подсознательное

Второе - необходимо для проектирования.

Чтобы достичь глубокого понимания например тех вопросов (ООП, потоки, и etс) как правило необходимы минимум 5 лет, 10 и больше.
При этом считаеться, что эти 5-10 лет вы активно занимаетесь практикой в данной области.

Это особенно верно, когда знания приходят от сторонних источников - например книг. Более лучше - живое общение.

А к чему это я всё говорю?

А это я прописал увы злой и обидный вывод.

Обидный он потому, что молодым хочеться всё и сразу. И как-то туго вериться, что мол, чтобы достич чего-нибудь высокого - надо не просто иметь 5 звёзд во лбу (а ведь каждый себя таким считает), а время и усилия.

И ещё. Махонькое дополнение.
В тот день когда я увижу замечательную ОСь на новых принципах проектирование, программирования или чего ещё, вот тогда посыплю голову пеплом, и признаюсь во всех смертных грехах.

На сией радостной Ноте - я заканчиваю этот флуд. Надеюсь он хоть кому-нибудь да будет полезен.

А до сей поры как сказал Г-н URI - подождём пока в этом топике появиться что-нить полезное для нас.

ВАУ!!! Не думал что мой топик вызовет столь красноречивые высказывания у Вас, товарищи, но я рад и тому что в вашем споре между строк иногда можно выцепить и в действительности интересные мысли :) . Я Задал этот топ
ради единственной цели - спроэктировать ОС так чтобы она могла послужить примером(и причем очень серьезным) для написания действительно реальной ОСи(пусть не сейчас и не сразу). Так вот созрели вопросы следующего плана, и пожалуйста не надо ссорится и гнать, Блин, друг на друга... сперва 7 раз подумайте, а потом один раз напишите :) это касаеться Edmondа и
Narkomaniusа. Ребята, вы же не дети, зачем вам это?
Ладно, организационные вопросы решили, надеюсь, перейду к делу - >
Насколько я знаю у нас есть
несколько моделей памяти: сегментная и страничная. А теперь внимание вопрос: Насколько страничная модель в
IA-32 отличаеться от IA-64 ? И еще какая модель памяти в Маковских процах? Ребята, огромная просьба, кому не жаль своих нескольких минут :) помогите с этими вопросами. Дело в том что встал вопрос о совместимости Микроядра с этими вышеперечисленными процами(ну возможно маки не включая), и очень хотелась хотябы знать как работают другие процы с памятью, чтобы выработать единые алгоритмы
ядра.

я уже вда раза пытался описать принципы работы ядра которое прогаю, но засыпал все время, ибо писал обычно 4 часа ночи. татенбаум во многом описывает механизмы прменяемые в юниксе, и которые решаются гораздо проще. книжка описывает систему мультикс, никсов немножко, винду под конец, и всякую элементарщину. вот описал бы он такую нетривиальную задачу, как удаление общего ресурса - был бы ему респект. я щас с этим зверски маюсь. хотя вроде решил - поднимать приоритет до реалтаймового(2 чтения и 2 записи в память, которая к тому же скэширована). мое личное мнение - Т. просто обсасывает банальности на 1к листов, не выдавая ничего ценного. уж для человека работавшего с осями много лет, мог бы не обобшение "мануалов для чайников" сделать а что нить стоющее рассмотрения. я например жалею теперь потраченых денек

Narkomanius
„+вот только qnx не надо копировать, даже в деталях.“
„хотя вроде решил - поднимать приоритет до реалтаймового(2 чтения и 2 записи в память, которая к тому же скэширована).“

Этот как раз тот метод, который используется в QNX для решения проблемы инверсии приоритетов (это когда более приоритетный процесс ждет менее приоритетного, захватившего ресурс). Только там приоритет поднимается до приоритета самого приоритетного из ожидающих потоков.

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

да не об этом речь. дело в том что когда процесс создал ресурс, он может им поделиться. создал семафор, получит
sem_t * my_sem=new semaphore(N_SEMS);
записал его нумер в свою долбицу ресурсов
p=get_current_process();
i=p->get_free_index();
if(i....
p->res_tab[p->get_free_index()]=(void*)my_sem;
вот так. теперь хотим чтоб он был доступен всем.
share_res(i,RW);---> это запрос в процесс ядра. ответ асинхронный, так что может и не сейчас ответить.
дык вот - при создании, проблемм нету!. юзать пожалуста. а вот удалить - траблы. если процесс, даже не прерываемый, юзает наш ресурс. то есть процесс-раздатчик вставил ему в таблу ресурсов адрес. пусть даже мы дождались ответа от раздатчика об отключении ссылок. но если кто то прошол по ссыле и ждет в спинблокировке? вот это бы подсказали кто нить...

Как же всё это надоело... 8(((

Вот смотрите:

1. Narkomanius > ... безопасность даже если запущен троян с правами рута ...

2. Black_mirror && Edmond > ... объекты ... методы ... интерфейсы ...

3. Narkomanius > ... семафоры ... семафоры ...
_______________________________

Первое называется "выработка (постановка) требований к системе".
Второе называется "разработка архитектуры системы"
Третье называется "реализация системы"

Бессмысленно разрабатывать архитектуру системы, если не поставлены требования...

Бессмысленно рассуждать о реализации, если не спроектирована архитектура...

А вы как считаете? ;)

согласен. а я тут причем?, сперва основа системы, потом подгонять её под заданные требования по мере их усложнения.
дождитесь первого рилиза, тогда поспорим. но вот абъектов я не потерплю. 3ОС развели тут..

Ну чтож ждем первой рабоче версии оси.

Печать зла.
Вот я и думаю, эту тему забудут.

ps
Экспримент.