OSDev

Какого размера должен быть PID, ThID и пр?
Знаю, что обычно DWORD. Это связано с производительностю или это - просто страховка от повторений?

_________________
Found a CPU. LAPIC ID: 00

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

Просто номер в ассоциативном массиве. Если, к примеру, вычеркиваем поток из списка, надо закрыть все его сокеты.

_________________
Found a CPU. LAPIC ID: 00

Тогда лучше исходить из максимально возможного в теории количества этих самых номеров: память впустую тратить смысла нет, производительности это ну никак не добавит. У меня, например, все номера имеют смысл только внутри задач, поэтому я сделал их 16-разрядными, причём у меня их несколько категорий, поскольку я считаю неправильным валить в одну кучу совершенно разные вещи. 16 бит, думается, для реальных случаев вполне достаточно: трудно представить себе задачу, которой потребуется держать открытыми больше 64 К файлов или имеющую такую кучу каких-либо объектов (тем более, что я работаю с АРМом, где пока 64-разрядных процессоров нет в принципе, ну а на 32-разрядных такое количество использовать проблематично: память, пожалуй, раньше кончится).

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

Я лично взял 4 байтрные. Так как массивы у меня динамические и они могут быть сколь угодно большими. Ограничения только память и тип переменной под размер.
16 бит это не мало 65 536, но с другой стороны и немного.
У некоторых в браузере бывает под 500вкладок открыто, а если учесть что во вкладке под 20 картинок то имеем 10 000.
На самом деле я реальную задачу придумать не могу. Но я не люблю ограничения. Во вторых история развития жёстких дисков учит что ресурсов никогда много не бывает. Вначале под адрес отвели три 8-битовых числа. Потом пришлось бороться с нехваткой 8 битовости и число цилиндров увеличили до 10 битового числа. Потом головки с 63 штук пришлось транслировать в 255. А ещё после в LBA не хватило 24 бит и сделали 28 бит которые сами понимаете закончились года через 2. А ещё было 32 битные переменные в функции вычисляющие адреса.
Вердикт каждые 4 года приходилось переписывать софт.

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

По поводу инкрементных пока не придумал где их можно использовать. Так как система может работать 24 часа 7 дней в неделю несколько лет. И в результате может переполнится счётчик. А что делать если 0 ресурс был выделен, но не освобождён? Получится коллизия.

Как уже говорил, зависит от целей, задач, возможностей. Моя система в первую очередь ориентирована на встраиваемые применения, а там с ресурсами напряжёнка. Например, она потенциально может использоваться на каком-нибудь STM32F103RB, у которого 128 килобайт флэш-памяти и всего 20 килобайт ОЗУ -- и в эти 20 килобайт надо впихнуть стек и данные системы, стеки и данные задач... В общем, развернуться особо негде. С другой стороны, мои 16-разрядные номера предназначены исключительно для идентификации системных объектов (события, мутексы, открытые файлы и т.д. и т.п.) в задачах, причём: 1) сами эти объекты разделены на несколько групп (пока их три -- файлы, разделы памяти и объекты синхронизации), у каждой из которых своя нумерация, поэтому один и тот же номер в зависимости от контекста может означать разные объекты; 2) у каждой задачи своя нумерация, никак не связанная с нумерацией в других задачах. Поэтому, думается, 64К номеров вполне хватит для любых разумных задачах не только на довольно хилых микроконтроллерах, но и на самых мощных АРМах. Нуа 500 вкладок... Вкладка -- не объект системы, и как там их браузер внутри себя будет именовать, это его сугубо личное дело.

В этом-то и проблема инкрементных идентификаторов, но для некоторых типов объектов они необходимы.

Это все правильно (отдельная нумерация по каждому типу объектов, локальная нумерация отдельных типов объектов), но а как же прямое обращение к глобальным объектам, проблема повторного использования "глобальных входов"?

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

Похоже, я опять сформулировал через G0. Объясняю.

Имеется таблица потоков и таблица процессов (максиум, на 2048 записей). Требуется привязать потоки к процессам. Можно, конечно, индефицировать по LDT, но как-то это по ламерский. Могут быть разные нюансы.
Имеет ли смысл брать 4 байта (исключительно из соображения быстродействия)?

_________________
Found a CPU. LAPIC ID: 00