How can you find the processor number a thread is running on?

I have a memory heap manager which partitions the heap into different segments based on the number of processors on the system. Memory can only be allocated on the partition that goes with the currently running thread's processor. This will help allow different process开发者_开发技巧ors to continue running even if two different ones want to allocate memory at the same time, at least I believe.

I have found the function GetCurrentProcessorNumber() for Windows, but this only works on Windows Vista and later. Is there a method that works on Windows XP?

Also, can this be done with pthreads on a POSIX system?

From output of man sched_getcpu:

NAME
       sched_getcpu - determine CPU on which the calling thread is running

SYNOPSIS
       #define _GNU_SOURCE
       #include <utmpx.h>

       int sched_getcpu(void);

DESCRIPTION
   sched_getcpu() returns the number of the CPU
   on which the calling thread is currently executing.

RETURN VALUE
   On success, sched_getcpu() returns a non-negative CPU number.
   On error, -1 is returned and errno is set to indicate the error.

SEE ALSO
   getcpu(2)

Unfortunately, this is Linux specific. I doubt there is a portable way to do this.

For XP, a quick google as revealed this:

https://www.cs.tcd.ie/Jeremy.Jones/GetCurrentProcessorNumberXP.htm Does this help?

In addition to Antony Vennard's answer and the code on the cited site, here is code that will work for Visual C++ x64 as well (no inline assembler):

DWORD GetCurrentProcessorNumberXP() {
   int CPUInfo[4];   
   __cpuid(CPUInfo, 1);
   // CPUInfo[1] is EBX, bits 24-31 are APIC ID
   if ((CPUInfo[3] & (1 << 9)) == 0) return -1;  // no APIC on chip
   return (unsigned)CPUInfo[1] >> 24;
}

A short look at the implementation of GetCurrentProcessorNumber() on Win7 x64 shows that they use a different mechanism to get the processor number, but in my (few) tests the results were the same for my home-brewn and the official function.

If all you want to do is avoid contention, you don't need to know the current CPU. You could just randomly pick a heap. Or you could have a heap per thread. Although you may get more or less contention that way, you would avoid the overhead of polling the current CPU, which may or may not be significant. Also check out Intel Thread Building Block's scalable_allocator, which may have already solved that problem better than you will.

This design smells bad to me. You seem to be making the assumption that a thread will stay associated with a specific CPU. That is not guaranteed. Yes, a thread may normally stay on a single CPU, but it doesn't have to, and eventually your program will have a thread that switches CPU's. It may not happen often, but eventually it will. If your design doesn't take this into account, then you will mostly likely eventually hit some sort of hard to trace bug.

Let me ask this question, what happens if memory is allocated on one CPU and freed on another? How will your heap handle that?