If-Koubou

Защо няма идентификатори за процеси на Windows с нечетни номера?

Защо няма идентификатори за процеси на Windows с нечетни номера? (Как да)

Ако обичате да бъркате с Windows и да учите, докато сте в движение, може да сте забелязали, че процесорните и идентификационните номера на Windows са четни и кратни на четири. Защо така? Днешната публикация "Суперуслуги Q & A" има отговорите на въпросите на любознателен читател.

Днешната сесия за въпроси и отговори ни идва с любезното съдействие на SuperUser - подразделение на Stack Exchange - обединяване на уеб сайтове с въпроси и отговори.

Въпроса

Reader на SuperUser Peter Hahndorf иска да разбере защо не съществуват нечетни идентификатори на процесите на Windows:

Има много начини да разгледате идентификационните номера на процесите в Windows. Използване на PowerShell:

Получавам този резултат:

Както можете да видите, всички идентификатори на процеса са четни, а не само, че те са всички кратни от четири. Можете да изглеждате толкова трудно, колкото искате, и никога няма да намерите идентификационен номер на процеса с нечетни номера, поне не на която и да е версия, базирана на Windows NT. Каква е причината за това?

Защо не съществуват идентификационни номера на процеса на Windows с нечетни номера?

Отговорът

Сътрудникът на SuperUser DavidPostill има отговора за нас:

Защо не съществуват идентификационни номера на процеса на Windows с нечетни номера?

Същият код, който разпределя дръжките на ядрото, се използва и за разпределяне на идентификационните номера на процеса и нишките. Тъй като дръжките на ядрото са няколко на четири, това са идентификационните номера на процеса и нишките.

Защо идентификационните номера на процеса и нишките са кратни на четири?

При операционните системи, базирани на Windows NT, идентификационните номера на процесите и нишките винаги се срещат като множество от четири. Това просто ли е съвпадение?

Да, това е просто съвпадение и не трябва да разчитате на него, тъй като не е част от договора за програмиране. Например процесът на Windows 95 и идентификационните номера на нишките не винаги са били умножени по четири. За сравнение, причината, поради която дръжките на ядрото винаги са на четири пъти, е част от спецификацията и ще бъде гарантирана в обозримо бъдеще.

Идентификационните процеси и нишките са кратни на четири като страничен ефект от повторното използване на кода. Същият код, който разпределя дръжките на ядрото, се използва и за разпределяне на идентификационните номера на процеса и нишките. Тъй като дръжките на ядрото са кратни на четири, така и идентификационните номера на процесите и нишките. Това е детайл на изпълнението, така че не пишете код, който разчита на него. Просто ви казвам да задоволите любопитството си.

Източник: Защо идентификационните номера на процеса и нишките са кратни на четири?

Защо дръжките на ядрото винаги са няколко от четири?

Нещо, което не е много добре известно е, че двата дънни дънки на дръжките на ядрото винаги са нулеви; с други думи, тяхната цифрова стойност винаги е кратно на четири. Имайте предвид, че това важи само за дръжките на ядрото; това не важи за псевдо дръжки или други видове дръжки (USER дръжки, дръжки GDI, мултимедийни дръжки и др.). Дръжките на ядрото са неща, които можете да преминете до функцията CloseHandle.

Това, че най-малко долният джоб на дръжките на ядрото винаги е нула се подразбира от функцията GetQueuedCompletionStatus, което показва, че можете да зададете долния бит на дръжката на събитието, за да потискате известието за завършване на порт. За да работи това, долният бит обикновено трябва да бъде нула.

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

Източник: Защо дръжките на ядрото винаги са няколко от четири?

Допълнителна информация

Старото ново нещо: Практическото развитие през еволюцията на Windows от Реймънд Чен (Главен инженер по проектиране на софтуер в)

Имате ли нещо, което да добавите към обяснението? Звучи в коментарите. Искате ли да прочетете повече отговори от други потребители на Stack Exchange? Вижте цялата тема на дискусията тук.