Центр информации по операционным системам: Форумы / Другие ОС / Реально ли сделать простую ОСь своими руками?

Центр информации по операционным системам :: Форумы :: Операционные системы :: Другие ОС		<< Предыдущая тема \| Следующая тема >>
Реально ли сделать простую ОСь своими руками?

Переход на страницу 1 2 3 ... 6 [7] 8 ... 11 12 13
Модераторы: Roman I Khimov, Wanderer, Dron

Автор

Добавил

grizlyk

Четверг 16.11.2006 10:07

ID пользователя #757

Зарегистрирован: Понедельник 06.11.2006 22:42
Сообщений: 72

Да вот еще что, наверняка кто нибудь попытается засунуть в Tobj_holder строку, а работать не будет, а виноват буду я. Поэтому я решил добавить и вторую часть файла HOLDER_H, для хранения строк в стеке:<div class='codec'>/*
Класс для хранения C массива чего-нибудь.
class Tarray_holder
*/

/*
Класс для хранения указателя на C массив чего-нибудь.
Полезен при использовании в качестве локальной переменной
для хранения полученных копий С-строк и их удаления при выходе
из функции. Можно выходить из функции в любом месте.

Массив в хранителе ведет себя как обычный массив,
но автоматически удаляется при выходе из функции.

Тип Tobj указывается без *, т.е.
Tarray_holder<const char> insted of
Tarray_holder<const char *> Массив должен быть выделен так: new Tobj[]

Объект такого класса не может быть скопирован, так
как размер массива не определить никак.
Массив с размером - Tarray
*/

namespace Pclasses{
template <class Tobj>class Tarray_holder
{
Tobj *ptr;

public:
//получить содержимое
//не для удаления снаружи
Tobj* get_array()const throw(){return ptr;}
Tobj* operator() ()const throw(){return get_array();}

//установить содержимое полученное от new Tobj[]
Tobj* set_array(Tobj *const obj)throw()
{
if(ptr!=obj)
{
delete[] ptr;
ptr=obj;
}
return ptr;
}
Tobj* operator= (Tobj *const obj)throw(){return set_array(obj);}

public:

Tarray_holder()throw():ptr(0){}
Tarray_holder(Tobj *const obj)throw():ptr(obj){}

~Tarray_holder()throw()
{
delete[] ptr;
ptr=0;
}

private:
Tarray_holder(const Tarray_holder&)throw():ptr(0){abort();}
void operator= (const Tarray_holder& obj)throw(){abort();}
};}</div>Во всех методах класса, где используется new, можно написать throw(std::exception) и выкидывать исключения ошибки выделения памяти ближайшему catch обработчику.

Наверх

Dron

Четверг 16.11.2006 10:09

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

Когда речь идет об объектном программировании - там есть еще десяток способов, как высвободить ресурсы.

В данном случае я почел пробросить исключение, ибо невозможность выделения ресурсов - для объекта фатально.

а конструкции типа for (;;) { break; } лично меня раздражают не меньше чем goto...

Это некрасиво!

Это какие-то костыли.
Помоему несколько вложенных if красивее и логичнее, тем более что и в вышеуказанной конструкции без условий ничего не получится.

Вообще все проблемы в том, что в одной функци пытаемся выделить несколько ресурсов, которые не планируем высвобождать в случае успеха. хотя си, что с него взять.

Но и от подхода много зависит.

Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее...

Андрей Валяев

Наверх

alman

Пятница 17.11.2006 00:34

ID пользователя #753

Зарегистрирован: Суббота 28.10.2006 01:21
Местонахождение: планета Земля
Сообщений: 95

captain cobalt написал(а) ...
В Active Oberon критические секции являются частью языка.
И перед нужными RETURN освобождение критической секции добавляется компилятором автоматически!

Круто. А на что похож его синтаксис? Может ли Active Oberon генерить объектные файлы, совместимые с GNU ld?

Наверх

alman

Пятница 17.11.2006 01:08

ID пользователя #753

Зарегистрирован: Суббота 28.10.2006 01:21
Местонахождение: планета Земля
Сообщений: 95

captain cobalt написал(а) ...
И ещё.

Если есть сборщик мусора, то для корректного управления ресурсами, ориентированными на память, не нужны ни исключения, ни IF-ы. Вообще ничего делать не надо. Как только по ошибке указатель на объект выйдет из области видимости, так о нём позаботится сборщик мусора.

Ну дык, кто бы спорил - так и есть.
А кто, кроме Java машины и NET машины, имеет сборщик мусора?

Наверх

alman

Пятница 17.11.2006 01:47

ID пользователя #753

Зарегистрирован: Суббота 28.10.2006 01:21
Местонахождение: планета Земля
Сообщений: 95

grizlyk написал(а) ...
Но вот обе конструкции с трудом могут заменить исключения, т.к. при создание одного объекта может быть бессмысленным без создания другого

Немного не согласен. Они не могут заменить исключения, потому что исключения позволяют "выскакивать" из некоторой вложенности стека, а break работает только в пределах циклов и switch.

grizlyk написал(а) ...
и к тому же, зачем создавать объекты, которые сразу придется удалять?

Ну почему же сразу?
Может случится так, что метод do_something() делает нечто сложное и ресурсоёмкое.

grizlyk написал(а) ...

написал(а) ...
Tobj1 obj1(new char[1024]);
Tobj2 obj2(obj1);

А в следующем примере много лучше сделать класс, делающий из указателя на размещенный в куче объект полноценную локальную переменную.

Нечто типа AutoPTR?

grizlyk написал(а) ...
В плохо структурированной программе, на скорую руку можно использовать следующий код, который я когда то использовал:

Это такая лицензия? Типа, назовите свою программу плохо структурированной, и вы можете использовать вышеприведённый код.

А если серьёзно, спасибо за шаблон. Могу ли я его использовать для своих нужд? Если да, то на каких условиях?

grizlyk написал(а) ...
Я думаю, что главная защита от блокировки ресурса - не надо пытаться распаралелить все что на глаза попадет.

В принципе, верно. Однако....

написал(а) ...
Любая активно используемая синхронизация говорит о том, что вы зря параллелите здесь. Особенно, если процессор реально один.

Дык, я с "пеной у рта" доказывал что синхронизация на уровне объектов - зло. Синхронизировать надо на уровне протоколов. Хотя, есть и исключения. Тот же сборщик мусора работает параллельно. Ну, почти параллельно.

grizlyk написал(а) ...
Хотя, я может быть, отстал от жизни и не знаю преимуществ такого подхода?

Если и отстали, то не более чем на минуту. Я в том смысле, что двухядерные процессоры уже в продаже. Многоядерные на подходе ( Cell? )... А методы построения информационных систем - традиционные.

В общем, ближайшее будущее за распараллеливанием на уровне протоколов/интерфейсов.
К примеру, если тактовая частота процессоров действительно подощла к физическому пределу, то в ближайшее время начнут параллелить всё подряд. Вот тут-то и выиграют те, кто распараллелит правильно.
<span class='smallblacktext'>[ Редактирование пятница 17.11.2006 01:53 ]</span>

Наверх

alman

Пятница 17.11.2006 01:57

ID пользователя #753

Зарегистрирован: Суббота 28.10.2006 01:21
Местонахождение: планета Земля
Сообщений: 95

Dron написал(а) ...
а конструкции типа for (;;) { break; } лично меня раздражают не меньше чем goto...

Это некрасиво!

Это какие-то костыли.

Дык, не будем спорить о вкусах. Главное чтобы программа нравилась автору и ещё кому-нить. Правильно?

Наверх

alman

Пятница 17.11.2006 02:10

ID пользователя #753

Зарегистрирован: Суббота 28.10.2006 01:21
Местонахождение: планета Земля
Сообщений: 95

grizlyk написал(а) ...
Во всех методах класса, где используется new, можно написать throw(std::exception) и выкидывать исключения ошибки выделения памяти ближайшему catch обработчику.

Спору нет. Исключения - очень удобная и полезная вещь.
Но с небольшой оговоркой. Они хороши для прикладного программиста. В некоторых случаях полезны для обработки реальных критических ситуаций на уровне системы.

Но проблемы начинаются тогда, когда эксепшенами подменяют обычный код возврата.

Вот пример:

Процесс, который обрабатывают сотни и тысячи запросов в секунду, например TCP/IP коннектов на загруженном сервере. При путешествии TCP/IP пакета по сети с ним может случится всё что угодно. Если на каждый битый пакет генерить эксепшн, то производительность сервера упадёт на порядки.

Мне так кажется, что обработка одного исключения по веремени равна паре-тройке сотен команд CMP + JNE + RET. А может быть и больше.

Приятно удивлюсь, если не прав.

Наверх

grizlyk

Пятница 17.11.2006 07:38

ID пользователя #757

Зарегистрирован: Понедельник 06.11.2006 22:42
Сообщений: 72

Есть еще такой неприятный момент у некоторых С++ компляторов, как копирование объекта возврата через конструктор копии, т.е. возвращаемый объект не создается сразу в стеке вызывающей функции, где для него резервируется память до вызова этой функции. Если для типа int это не страшно, то для больших объектов в ядре ОС это очень неэффективно.

alman написал(а) ...
Немного не согласен. Они не могут заменить исключения, потому что исключения озволяют "выскакивать" из некоторой вложенности стека, а break работает только в пределах циклов и switch.

Главное, я думаю, что исключения позволяют выскакивать из конструкторов локальных объектов, что выглядит как "некоторой вложенности стека", т.е. нельзя с break.

То, что кто-то тут написал с помощью goto, наверняка и делает С++ при обработке исключений. Только надо разобраться с конструкторами.

Если произошел вход в конструктор, то выход по исключению из конструктора может быть:
1. из полностью проинициализированного (все конструкторы после ":" отработали), но только частично сконструированного объекта (не весь код в "{}" отработал);
2. из частично проинициализированного (не все конструкторы после ":" отработали), но не сконструированного объекта (код в {} не работал).

С первым случаем все понятно, перед выходом из функции надо вызывать обычный деструктор, но вот со вторым случаем как быть? Компилятор должен знать сколько конструкторов после ":" отработало и вызвать для них деструкторы перед выходом из функции.

Теоретически конструктор можно рассмотреть как две части, вызываемые последовательно: автоматически создаваемую компилятором функцию-инициализатор, для которой параметры инициализации (после ":") выступают как локальные объекты и конструктор пользователя (код в "{}").

Если исключение произошло в инициализаторе, при вызове конструктора для какого-то из локальных объектов инициализатора, то обычный деструктор не вызывается, а деструкторы для уже инициализированных локальных объектов инициализатора вызываются внутри инициализатора по правилам обычной функции.

Должно работать и почти эффективно. Только размер кода деструктора вырастает.

alman написал(а) ...
Нечто типа AutoPTR?

AutoPTR не является частью С++, так ведь? Наверное что-то вроде него.

alman написал(а) ...

grizlyk написал(а) ...
В плохо структурированной программе

Это такая лицензия?

Нет. В хорошо структурированной программе потребность в Tobj_holder может не возникать. Этот код можно использовать свободно, как и код из ваших примеров, но найти хорошее применение этот код сможет, когда программа пишется, (как это может быть для ОС) на смеси С/С++ конструкций. В нем существует потенциальная опасность несинхронного изменения адреса, могут быть трудности с модификаторами и т.п. (Исключения, конечно, лучше передавать по ссылке или сразу нужный класс)

Наверх

grizlyk

Пятница 17.11.2006 08:00

ID пользователя #757

Зарегистрирован: Понедельник 06.11.2006 22:42
Сообщений: 72

alman написал(а) ...

grizlyk написал(а) ...
не надо пытаться распаралелить все что на глаза попадет.

В принципе, верно. Однако....

grizlyk написал(а) ...
Любая активно используемая синхронизация говорит о том, что вы зря параллелите здесь. Особенно, если процессор реально один.

Дык, я с "пеной у рта" доказывал что синхронизация на уровне объектов - зло. Синхронизировать надо на уровне протоколов. Хотя, есть и исключения.

Это как это?

alman написал(а) ...
К примеру, если тактовая частота процессоров действительно подошла к физическому пределу, то в ближайшее время начнут параллелить всё подряд.

Я думаю, что параллелить будет сам процессор, а вот нити нужны скорее программисту, чем процессору.

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

Без нитей действительно разные алгоритмы перемешиваются между собой, что все время происходит в ДОС, где в главном цикле последовательно и маленькими частями: едят, чистят унитаз и ездят на машине.

С другой стороны, описывать четырьмя нитями решение выражения y(4)=ax*x(1)+bx(2)+c(3) , когда нити 1,2,3 конкурируют за право посчитать, а нить 4 ждет результат, плохо.

alman написал(а) ...
Вот тут-то и выиграют те, кто распараллелит правильно.

А правильно это как?

Наверх

grizlyk

Пятница 17.11.2006 08:21

ID пользователя #757

Зарегистрирован: Понедельник 06.11.2006 22:42
Сообщений: 72

alman написал(а) ...
Спору нет. Исключения - очень удобная и полезная вещь. Но с небольшой оговоркой. Они хороши для прикладного программиста.

В некоторых случаях полезны для обработки реальных критических ситуаций на уровне системы.
...
Если на каждый битый пакет генерить эксепшн, то производительность сервера упадёт на порядки.

Мне так кажется, что обработка одного исключения по веремени ...

Исключения в хорошо спроектированной системе нужны реально только для состояния, из которого нет восстановления, по крайней мере на уровне возникновения ошибки.

Нельзя использовать исключения для обычного, хорошо предвидимого состояния: для протокола TCP - задержка/потеря данных, для временной недоступности часто перевыделяемого дефицитного ресурса и т.п.

Исключения нужны реально только для сообщения о непредвиденной ошибке, для которой результат работы функции не имеет смысла (работа не начиналась, неправильные параметры и т.п.). Обычная реакция на исключение: напечатать сообщение и завершить работу.

Нет большой разницы, как долго будет завершаться программа (как долго будет выбрасываться исключение), но возможнось не думать о том, как выделять/освобождать ресурсы, а заниматься алгоритмом, стоит того чтобы использовать исключения.

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

Наверх

Переход на страницу 1 2 3 ... 6 [7] 8 ... 11 12 13
Перейти: Наверх