views:

408

answers:

3

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 processors 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?

+3  A: 

For XP, a quick google as revealed this: https://www.cs.tcd.ie/Jeremy.Jones/GetCurrentProcessorNumberXP.htm Does this help?

Ninefingers
Yes, thank you. This appears to work on both Linux and Windows, as long as it is running on an x86 platform.
Patrick Niedzielski
@Patrick I don't think this works on Linux, just XP in that form anyway.
Ninefingers
The assembly language itself is not dependent upon the operating systems. As for the difference between _asm, `__asm__`, asm, etc. on different platforms and compilers, that I can deal with.
Patrick Niedzielski
@Patrick Ok yep, have just looked it up in the assembly docs, it is an actual instruction not an API call like a first thought... works fine for me on x86-64 linux too!
Ninefingers
+4  A: 

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.

Ilia K.
A quick perusal of the pthread documentation doesn't reveal any calls that are part of the phtread API that do this.
Omnifarious
Thanks Ilia. Though this only works on Linux, it is a nice and clean function call. If/when I need to port to another kernel, I can just change this function call to a modified version of the assembler above.
Patrick Niedzielski
A: 

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?

shf301
The freeing processor does not matter. In each block, I save a pointer to the correct partition. I just call the function once per allocation, so this is not a problem.While it is true that the current thread may change processors, this also would not result in any problems with my design (in theory :P). The heap itself is still a locked heap. So, if two different threads want to allocate on the same partition, one will be locked until the other finishes. This design just minimises the chance that one processor will lock the execution of another.
Patrick Niedzielski
The problem is presumably that a thread might migrate _while_ allocating memory. This may cause a thread to determine it runs on CPU #0, get a pointer to heap #0, then migrate to CPU #1, then try to allocate from heap #0.
MSalters
That is fine. My heap is a locked heap itself, so even without this processor number black magic, it would work fine. I am optimising it so as not to lock out other processors that could be something more useful. So in the case both of you pointed out, another processor will be locked from allocation. The main point of my design, though, is that this is more unlikely to happen, so is thus worth the effort.
Patrick Niedzielski