Pourquoi n'y a-t-il pas d'identifiants de processus Windows impairs-numérotés?

Table des matières:

Pourquoi n'y a-t-il pas d'identifiants de processus Windows impairs-numérotés?
Pourquoi n'y a-t-il pas d'identifiants de processus Windows impairs-numérotés?

Vidéo: Pourquoi n'y a-t-il pas d'identifiants de processus Windows impairs-numérotés?

Vidéo: Pourquoi n'y a-t-il pas d'identifiants de processus Windows impairs-numérotés?
Vidéo: Comment Désactiver la Synchronisation OneDrive sur Windows 10 - YouTube 2024, Avril
Anonim
Si vous aimez bricoler avec Windows et apprendre au fur et à mesure, vous avez peut-être remarqué que les identificateurs de processus et de fil Windows sont numérotés de manière paire et sont des multiples de quatre. Pourquoi donc? L’article d’aujourd’hui sur le SuperUser Q & R contient les réponses aux questions d’un lecteur curieux.
Si vous aimez bricoler avec Windows et apprendre au fur et à mesure, vous avez peut-être remarqué que les identificateurs de processus et de fil Windows sont numérotés de manière paire et sont des multiples de quatre. Pourquoi donc? L’article d’aujourd’hui sur le SuperUser Q & R contient les réponses aux questions d’un lecteur curieux.

La séance de questions et réponses d’aujourd’hui nous est offerte par SuperUser, une sous-division de Stack Exchange, un groupe de sites Web de questions-réponses dirigé par la communauté.

La question

Le lecteur de superutilisateur Peter Hahndorf veut savoir pourquoi il n’existe pas d’ID de processus Windows impairs:

There are many ways to look at the process IDs in Windows. Using PowerShell:

I get this result:
I get this result:
As you can see, all the process IDs are even-numbered, not only that, they are all multiples of four. You can look as hard as you want and you will never find an odd-numbered process ID, at least not on any version that is Windows NT-based. What is the reason for this?
As you can see, all the process IDs are even-numbered, not only that, they are all multiples of four. You can look as hard as you want and you will never find an odd-numbered process ID, at least not on any version that is Windows NT-based. What is the reason for this?

Pourquoi n'y a-t-il pas d'identifiants de processus Windows impairs?

La réponse

DavidPostill, contributeur à SuperUser, a la solution pour nous:

Why are there no odd-numbered Windows process IDs?

The same code that allocates kernel handles is also used to allocate process and thread IDs. Since kernel handles are a multiple of four, so are process and thread IDs.

Why are process and thread IDs multiples of four?

On Windows NT-based operating systems, process and thread IDs always happen to be a multiple of four. Is this just a coincidence?

Yes, it is just a coincidence, and you should not rely on it since it is not part of the programming contract. For example, Windows 95 process and thread IDs were not always multiples of four. By comparison, the reason that kernel handles are always a multiple of four is part of the specification and will be guaranteed for the foreseeable future.

Process and thread IDs are multiples of four as a side-effect of code reuse. The same code that allocates kernel handles is also used to allocate process and thread IDs. Since kernel handles are multiples of four, so are process and thread IDs. This is an implementation detail, so do not write code that relies on it. I am just telling you to satisfy your curiosity.

Source: Why are process and thread IDs multiples of four?

Why are kernel handles always a multiple of four?

Something that is not very well known is that the bottom two bits of kernel handles are always zero; in other words, their numeric value is always a multiple of four. Note that this applies only to kernel handles; it does not apply to pseudo-handles or to any other type of handle (USER handles, GDI handles, multimedia handles, etc.). Kernel handles are things you can pass to the CloseHandle function.

That at least the bottom bit of kernel handles are always zero is implied by the GetQueuedCompletionStatus function, which indicates that you can set the bottom bit of the event handle to suppress completion port notification. In order for this to work, the bottom bit must normally be zero.
That at least the bottom bit of kernel handles are always zero is implied by the GetQueuedCompletionStatus function, which indicates that you can set the bottom bit of the event handle to suppress completion port notification. In order for this to work, the bottom bit must normally be zero.

This information is not useful for most application writers, which should continue to treat handles as opaque values. The people who would be interested in tag bits are those who are implementing low-level class libraries or are wrapping kernel objects inside a larger framework.

Source: Why are kernel handles always a multiple of four?

Further Reading

The Old New Thing: Practical Development Throughout the Evolution of Windows by Raymond Chen (Principal Software Design Engineer at Microsoft)

Avez-vous quelque chose à ajouter à l'explication? Sound off dans les commentaires. Voulez-vous lire plus de réponses d'autres utilisateurs de Stack Exchange doués en technologie? Découvrez le fil de discussion complet ici.

Conseillé: