了解 sem_open()

Question

I am using named semaphores, here is my process code of sem_proc.cpp:

# include <iostream>
# include <string.h>
# include <unistd.h>
# include <semaphore.h>
# include <fcntl.h>

using namespace std;

int main(){
  sem_t *sem;
  string sem_name = "/my_sem";
  int value = 1;

  sem = sem_open(sem_name.c_str(), O_CREAT, 0644, value);
  cout << "sem_addr : " << sem << endl;
  
  cout << "sem_wait_result: " << sem_wait(sem) << endl;
  cout << "Enterd into CS" << endl;
  sleep(5);   // sleep for 5 seconds
  cout << "Waked up and now going out of CS" << endl;
  sem_post(sem);
  
  sem_close(sem);
  return 0;
}

I have compiled with:

g++ sem_proc.cpp -lpthread

then run the code on two different terminal as:

./a.out

Output of terminal 1 was:

sem_addr : 0x7fef162de000
sem_wait_result: 0
Enterd into CS
Waked up and now going out of CS

Output of terminal 2 was:

sem_addr : 0x7f53836a2000
sem_wait_result: 0
Enterd into CS
Waked up and now going out of CS

Shouldn't the address of the named semaphore with name "/my_sem" in both the terminal be same as I am using O_CREAT during sem_open, or I am missing something?

Answer 1

Do not expect semaphores to have the same memory address in different processes. This is not the semaphore itself, sem_t is the program's copy of data needed to interface with the semaphore. The semaphore itself is handled by the OS.

The exact location is complicated by a lot of factors: Address randomization, malloc, mmap, etc.

Answer 2

A sem_t , in the C standard library, is a structure that holds information about the semaphore, and it is created usually by calling mmap with the flag MAP_SHARED to tell the kernel to use a pre-allocated Shared Memory area. Semaphores (in Unix systems) are really just file descriptors, so mapping them into memory needs to be shared amongst threads.

The memory address of this mapping is up to the kernel to decide, based on other mapped files and areas, and that explains why it is different each time. The kernel will randomize the address layout, in order to prevent exploits caused by buffer-overflows.

For more information, read up on the mmap system call.