堆栈说明 memory 分配 function - C++

Question

I am trying to understand a program which uses multi-threading with shared-memory. The parent thread calls the following function and I don't quite understand how it works.

#define MAX_STACK_SIZE 16384  // 16KB  of stack

/*!
 * Writes to a 16 KB buffer on the stack. If we are using 4K pages for our
 * stack, this will make sure that we won't have a page fault when the stack
 * grows.  Also mlock's all pages associated with the current process, which
 * prevents the program from being swapped out.  If we do run out of
 * memory, the robot program will be killed by the OOM process killer (and
 * leaves a log) instead of just becoming unresponsive.
 */
void HardwareBridge::prefaultStack() {
  printf("[Init] Prefault stack...\n");
  volatile char stack[MAX_STACK_SIZE];
  memset(const_cast<char*>(stack), 0, MAX_STACK_SIZE);
  if (mlockall(MCL_CURRENT | MCL_FUTURE) == -1) {
    initError(
        "mlockall failed.  This is likely because you didn't run robot as "
        "root.\n",
        true);
  }
}
       
//Parent Thread
void HardwareBridge::run(){

  printf("[HardwareBridge] Init stack\n");
  prefaultStack();

  //printf("[HardwareBridge] Init scheduler\n");  // Commented because unrelated to current question
  //setupScheduler();
      
  // Calls multiple threads here
 
  for(;;){
  usleep(10000000);
  }
}

Can someone explain what's the purpose of this function. Based on the comment, I could understand that it prevent the stack size from growing beyond 16KB. However, the shared memory are predominantly allocated dynamically using new keyword in the program. Isn't dynamic memory allocation takes place in the heap rather than the stack? How does the function helps in this scenario.

Answer 1

Based on the comment, I could understand that it prevent the stack size from growing beyond 16KB.

That's not what the comment says and not what the function does.

Can someone explain what's the purpose of this function.

The comment explains it. The function does two things:

• It pre-allocates 16K of stack.
• It "locks" the allocated memory which prevents it from being swapped to disk.

These two things guarantee that there won't be a page fault when the stack usage grows (as long as it doesn't grow beyond 16K).

However, the shared memory are predominantly allocated dynamically

True. This means that shared, or other dynamic memory allocation is irrelevant to the function.

Answer 2

as per my understanding, the reply is inline

1. Based on the comment, I could understand that it prevent the stack size from growing beyond 16KB.

Nope. prefaultStack function has char[MAX_STACK_SIZE] on its stack, so stack segment of main process will be of size 4 pages + (stack size for main function). And any virtual memory pages of this process (along with any allocated in future as stack or heap grows) will not be swapped out to the swap area because mlockall is called with MCL_CURRENT and MCL_FUTURE https://linux.die.net/man/2/mlockall . This is the only functionality of this function. Nothing related to dynamic memory, heap or shared memory.

2. However, the shared memory are predominantly allocated dynamically using new keyword in the program.

you are dealing with the multi-threading, so dynamic memory or heap address space is shared among the threads. This code does nothing with respect to shared memory between two processes.

3. Isn't dynamic memory allocation takes place in the heap rather than the stack? How does the function helps in this scenario.

Dynamic memory is allocated from the heap. And this function does not deal in any way with heap. This code only makes sure that all the stack and heap pages (CURRENT allocated and FUTURE allocated) of the process never swapped out to the swap area preventing any page faults which are time-consuming costlier operations.

Answer 3

In prefaultStack() you make sure that stack is incremented at least 16K from its previous size. Then by calling mlockall() you lock current memory pages to memory, preventing them from being swapped out. After that you exit the function.

I would say that the only real effect of this is that you ensure that no matter what, the calling thread will have at least 16K of stack available even if later on some hungry process eats up all remaining memory.