Map shared memory linux shell

Memory sharing in Linux with MMAP

MMAP is a UNIX system call that maps files into memory. It’s a method used for memory-mapped file I/O. It brings in the optimization of lazy loading or demand paging such that the I/O or reading file doesn’t happen when the memory allocation is done, but when the memory is accessed. After the memory is no longer needed it can be cleared with munmap call. MMAP supports certain flags or argument which makes it suitable for allocating memory without file mapping as well. In Linux kernel, the malloc call uses mmap with MAP_ANONYMOUS flag for large allocations.

In this article, I’ll be explaining how what mmap is and how it can be used for sharing memory in Linux. It kind of is the backbone of shared memory in Android.

Arguments and flags

mmap() creates a new mapping in the virtual address space of the calling process. If you check out the Linux kernel page for mmap you’ll see several arguments and flags. On the other hand, munmap() is used to free the allocated memory.

MMAP definition

• The addr specifies the starting address of the allocation and if it’s passed as NULL the kernel chooses the starting address.
• The length argument specifies the length of allocation in bytes and should be > 0 .
• The prot argument describes the protection level
  • PROT_EXEC Pages may be executed.
  • PROT_READ Pages may be read.
  • PROT_WRITE Pages may be written.
  • PROT_NONE Pages may be not be accessed.

  The flags can be passed with bitwise OR operator and the default protection level is

  MUNMAP definition

  The munmap() system call deletes the mappings for the specified address range and causes further references to addresses within the range to generate invalid memory references. The region is also automatically unmapped when the process is terminated. On the other hand, closing the file descriptor does not unmap the region.

  • The addr is the address of allocation to free, essentially what you got from calling the mmap() . After calling munmap() , any access on the memory address shall raise SIGSEV errors.
  • The length determines the area of memory to clear. The area of memory from addr to addr + length would be freed on this call.

  Sharing memory with MMAP

  MMAP can be thought of as the core memory allocation API in Linux and several high-level constructs take advantage of this for providing various features. Linux kernel is the core of Android OS and components like ASHMEM uses MMAP in its core. ASHMEM is used for sharing memory in Android in different components like ContentProviders or Binder IPC.

  Sharing between parent and child

  This is fairly simple to visualize. A mmap allocation with MAP_SHARED flag can be accessed directly by the child process.

  This is very helpful in sharing the memory of core components in Android. All applications in Android are forked from a bare-bone process called Zygote which loads the core libraries and code required by all applications with mmap . Zygote is loaded into memory on device boot and when a user attempts to open an application for the first time the system forks Zygote and then the application logic is initialized.

  Sharing between siblings

  While it’s easy to visualize how memory can be shared in ancestry between a parent and child. The logic is very similar but involves Inter-Process Communication (IPC). Two common ways to achieve this could be:

  Without extra management layer

  The concept is similar, the two processes say Process 1 and Process 2 can communicate with each other via certain IPC technology.

  • Process 1 creates a file and allocates memory on that with MAP_SHARED flag and appropriate protection level and length. This process can write some data in the allocated memory space.
  • Process 1 shares this file descriptor with Process 2 via a certain IPC method.
  • Process 2 receives this file descriptor and calls mmap on that. So the system returns the virtual address of the same memory allocation and based on the protection levels set by Process 1 , Process 2 can read, write or execute the shared memory pages.

  However, these processes are responsible for explicitly deallocating memory, otherwise, it cannot be reused by another process in need of memory.

  With an extra management layer

  In this case, another process acts as the manager of shared memory and exposes interface or methods to allocate or retrieve memory allocations. Let’s say there is a memory manager called XMAN and exposes APIs like this:

  • Process 1 could allocate a chunk of memory using Xman_allocate() and share the Xman_allocation.fd with another process via a certain IPC mechanism.
  • Process 2 could use Xman_get() to get the same allocation and act on it.
  • Any of these processes could use the Xman_free() to explicitly free the memory.

  While the way of dealing with shared memory seems very similar with or without a manager instance, a centralized manager can abstract some memory freeing techniques thus taking away the expectation of being good citizens from the calling processes like:

  • Freeing memory after use, the Manager can take care of freeing when the calling processes die.
  • Some components like ASHMEM, support features like PINNING and UNPINNING section of memory which allows the consumer process to set which part of memory can be cleared when the system is out of free memory. This protects the consumer apps from being killed by the Low Memory Killer (LMK) when it’s reclaiming memory. ASHMEM has its process on deciding which UNPINNED memory to clear when available memory is system goes below a certain threshold.

  MISC: MMAP is faster than reading a file in blocks

  While exploring these concepts I was wondering how file-backed memory manages to be performant while file IO operation like read() is generally considered much slower than memory operations. There are a few interesting StackOverflow questions like Why mmap() is faster than sequential IO? and mmap() vs. reading blocks which answer this questions pretty well.

  But they won’t give you a short answer like — Because MMAP is magic! They are long reads.

  I wish I could add a TL;DR; answer to this question here but there isn’t one. Both mmap() and read() have their pros and cons and could be more performant in different situations. While mmap() seems like magic, it’s simply not.

  Future readings

  In the future, I intend to write about what ASHMEM is, how it works, why it was brought when MMAP existed and examples of how it’s been used in Android. Another interesting memory manager in Android is the ION memory manager which was added to Linux kernel in 2011 by a patch from Google to solve issues around large memory allocations needed by components like GPU, display, camera, etc.

  Источник

  Знакомство с межпроцессным взаимодействием на Linux

  Межпроцессное взаимодействие (Inter-process communication (IPC)) — это набор методов для обмена данными между потоками процессов. Процессы могут быть запущены как на одном и том же компьютере, так и на разных, соединенных сетью. IPC бывают нескольких типов: «сигнал», «сокет», «семафор», «файл», «сообщение»…

  Отступление: данная статья является учебной и расчитана на людей, только еще вступающих на путь системного программирования. Ее главный замысел — познакомиться с различными способами взаимодействия между процессами на POSIX-совместимой ОС.

  Именованный канал

  Для передачи сообщений можно использовать механизмы сокетов, каналов, D-bus и другие технологии. Про сокеты на каждом углу можно почитать, а про D-bus отдельную статью написать. Поэтому я решил остановиться на малоозвученных технологиях отвечающих стандартам POSIX и привести рабочие примеры.

  Рассмотрим передачу сообщений по именованным каналам. Схематично передача выглядит так:
  
  Для создания именованных каналов будем использовать функцию, mkfifo():

  Примечание: mode используется в сочетании с текущим значением umask следующим образом: (mode &

  umask). Результатом этой операции и будет новое значение umask для создаваемого нами файла. По этой причине мы используем 0777 (S_IRWXO | S_IRWXG | S_IRWXU), чтобы не затирать ни один бит текущей маски.

  Как только файл создан, любой процесс может открыть этот файл для чтения или записи также, как открывает обычный файл. Однако, для корректного использования файла, необходимо открыть его одновременно двумя процессами/потоками, одним для получение данных (чтение файла), другим на передачу (запись в файл).

  В случае успешного создания FIFO файла, mkfifo() возвращает 0 (нуль). В случае каких либо ошибок, функция возвращает -1 и выставляет код ошибки в переменную errno.

  Типичные ошибки, которые могут возникнуть во время создания канала:

  • EACCES — нет прав на запуск (execute) в одной из директорий в пути pathname
  • EEXIST — файл pathname уже существует, даже если файл — символическая ссылка
  • ENOENT — не существует какой-либо директории, упомянутой в pathname, либо является битой ссылкой
  • ENOSPC — нет места для создания нового файла
  • ENOTDIR — одна из директорий, упомянутых в pathname, на самом деле не является таковой
  • EROFS — попытка создать FIFO файл на файловой системе «только-на-чтение»

  Чтение и запись в созданный файл производится с помощью функций read() и write().

  Пример

  mkfifo.c

  Мы открываем файл только для чтения (O_RDONLY). И могли бы использовать O_NONBLOCK модификатор, предназначенный специально для FIFO файлов, чтобы не ждать когда с другой стороны файл откроют для записи. Но в приведенном коде такой способ неудобен.

  Компилируем программу, затем запускаем ее:

  В соседнем терминальном окне выполняем:

  В результате мы увидим следующий вывод от программы:

  Разделяемая память

  Следующий тип межпроцессного взаимодействия — разделяемая память (shared memory). Схематично изобразим ее как некую именованную область в памяти, к которой обращаются одновременно два процесса:
  
  Для выделения разделяемой памяти будем использовать POSIX функцию shm_open():

  Функция возвращает файловый дескриптор, который связан с объектом памяти. Этот дескриптор в дальнейшем можно использовать другими функциями (к примеру, mmap() или mprotect()).

  Целостность объекта памяти сохраняется, включая все данные связанные с ним, до тех пор пока объект не отсоединен/удален (shm_unlink()). Это означает, что любой процесс может получить доступ к нашему объекту памяти (если он знает его имя) до тех пор, пока явно в одном из процессов мы не вызовем shm_unlink().

  Переменная oflag является побитовым «ИЛИ» следующих флагов:

  • O_RDONLY — открыть только с правами на чтение
  • O_RDWR — открыть с правами на чтение и запись
  • O_CREAT — если объект уже существует, то от флага никакого эффекта. Иначе, объект создается и для него выставляются права доступа в соответствии с mode.
  • O_EXCL — установка этого флага в сочетании с O_CREATE приведет к возврату функцией shm_open ошибки, если сегмент общей памяти уже существует.

  Как задается значение параметра mode подробно описано в предыдущем параграфе «передача сообщений».

  После создания общего объекта памяти, мы задаем размер разделяемой памяти вызовом ftruncate(). На входе у функции файловый дескриптор нашего объекта и необходимый нам размер.

  Пример

  Следующий код демонстрирует создание, изменение и удаление разделяемой памяти. Так же показывается как после создания разделяемой памяти, программа выходит, но при следующем же запуске мы можем получить к ней доступ, пока не выполнен shm_unlink().

  shm_open.c

  После создания объекта памяти мы установили нужный нам размер shared memory вызовом ftruncate(). Затем мы получили доступ к разделяемой памяти при помощи mmap(). (Вообще говоря, даже с помощью самого вызова mmap() можно создать разделяемую память. Но отличие вызова shm_open() в том, что память будет оставаться выделенной до момента удаления или перезагрузки компьютера.)

  Компилировать код на этот раз нужно с опцией -lrt:

  Смотрим что получилось:

  Аргумент «create» в нашей программе мы используем как для создания разделенной памяти, так и для изменения ее содержимого.

  Зная имя объекта памяти, мы можем менять содержимое разделяемой памяти. Но стоит нам вызвать shm_unlink(), как память перестает быть нам доступна и shm_open() без параметра O_CREATE возвращает ошибку «No such file or directory».

  Семафор

  Семафор — самый часто употребляемый метод для синхронизации потоков и для контролирования одновременного доступа множеством потоков/процессов к общей памяти (к примеру, глобальной переменной). Взаимодействие между процессами в случае с семафорами заключается в том, что процессы работают с одним и тем же набором данных и корректируют свое поведение в зависимости от этих данных.

  Есть два типа семафоров:

  1. семафор со счетчиком (counting semaphore), определяющий лимит ресурсов для процессов, получающих доступ к ним
  2. бинарный семафор (binary semaphore), имеющий два состояния «0» или «1» (чаще: «занят» или «не занят»)

  Рассмотрим оба типа семафоров.

  Семафор со счетчиком

  Смысл семафора со счетчиком в том, чтобы дать доступ к какому-то ресурсу только определенному количеству процессов. Остальные будут ждать в очереди, когда ресурс освободится.

  Итак, для реализации семафоров будем использовать POSIX функцию sem_open():

  В функцию для создания семафора мы передаем имя семафора, построенное по определенным правилам и управляющие флаги. Таким образом у нас получится именованный семафор.
  Имя семафора строится следующим образом: в начале идет символ «/» (косая черта), а следом латинские символы. Символ «косая черта» при этом больше не должен применяться. Длина имени семафора может быть вплоть до 251 знака.

  Если нам необходимо создать семафор, то передается управляющий флаг O_CREATE. Чтобы начать использовать уже существующий семафор, то oflag равняется нулю. Если вместе с флагом O_CREATE передать флаг O_EXCL, то функция sem_open() вернет ошибку, в случае если семафор с указанным именем уже существует.

  Параметр mode задает права доступа таким же образом, как это объяснено в предыдущих главах. А переменной value инициализируется начальное значение семафора. Оба параметра mode и value игнорируются в случае, когда семафор с указанным именем уже существует, а sem_open() вызван вместе с флагом O_CREATE.

  Для быстрого открытия существующего семафора используем конструкцию:
  , где указываются только имя семафора и управляющий флаг.

  Пример семафора со счетчиком

  Рассмотрим пример использования семафора для синхронизации процессов. В нашем примере один процесс увеличивает значение семафора и ждет, когда второй сбросит его, чтобы продолжить дальнейшее выполнение.

  sem_open.c

  В одной консоли запускаем:

  В соседней консоли запускаем:

  Бинарный семафор

  Вместо бинарного семафора, для которого так же используется функция sem_open, я рассмотрю гораздо чаще употребляемый семафор, называемый «мьютекс» (mutex).

  Мьютекс по существу является тем же самым, чем является бинарный семафор (т.е. семафор с двумя состояниями: «занят» и «не занят»). Но термин «mutex» чаще используется чтобы описать схему, которая предохраняет два процесса от одновременного использования общих данных/переменных. В то время как термин «бинарный семафор» чаще употребляется для описания конструкции, которая ограничивает доступ к одному ресурсу. То есть бинарный семафор используют там, где один процесс «занимает» семафор, а другой его «освобождает». В то время как мьютекс освобождается тем же процессом/потоком, который занял его.

  Без мьютекса не обойтись в написании, к примеру базы данных, к которой доступ могут иметь множество клиентов.

  Для использования мьютекса необходимо вызвать функцию pthread_mutex_init():

  Функция инициализирует мьютекс (перемнную mutex) аттрибутом mutexattr. Если mutexattr равен NULL, то мьютекс инициализируется значением по умолчанию. В случае успешного выполнения функции (код возрата 0), мьютекс считается инициализированным и «свободным».

  Типичные ошибки, которые могут возникнуть:

  • EAGAIN — недостаточно необходимых ресурсов (кроме памяти) для инициализации мьютекса
  • ENOMEM — недостаточно памяти
  • EPERM — нет прав для выполнения операции
  • EBUSY — попытка инициализировать мьютекс, который уже был инициализирован, но не унечтожен
  • EINVAL — значение mutexattr не валидно

  Чтобы занять или освободить мьютекс, используем функции:

  Функция pthread_mutex_lock(), если mutex еще не занят, то занимает его, становится его обладателем и сразу же выходит. Если мьютекс занят, то блокирует дальнейшее выполнение процесса и ждет освобождения мьютекса.
  Функция pthread_mutex_trylock() идентична по поведению функции pthread_mutex_lock(), с одним исключением — она не блокирует процесс, если mutex занят, а возвращает EBUSY код.
  Фунция pthread_mutex_unlock() освобождает занятый мьютекс.

  Коды возврата для pthread_mutex_lock():

  • EINVAL — mutex неправильно инициализирован
  • EDEADLK — мьютекс уже занят текущим процессом

  Коды возврата для pthread_mutex_trylock():

  • EBUSY — мьютекс уже занят
  • EINVAL — мьютекс неправильно инициализирован

  Коды возврата для pthread_mutex_unlock():

  • EINVAL — мьютекс неправильно инициализирован
  • EPERM — вызывающий процесс не является обладателем мьютекса

  Пример mutex

  mutex.c

  Данный пример демонстрирует совместный доступ двух потоков к общей переменной. Один поток (первый поток) в автоматическом режиме постоянно увеличивает переменную counter на единицу, при этом занимая эту переменную на целую секунду. Этот первый поток дает второму доступ к переменной count только на 10 миллисекунд, затем снова занимает ее на секунду. Во втором потоке предлагается ввести новое значение для переменной с терминала.

  Если бы мы не использовали технологию «мьютекс», то какое значение было бы в глобальной переменной, при одновременном доступе двух потоков, нам не известно. Так же во время запуска становится очевидна разница между pthread_mutex_lock() и pthread_mutex_trylock().

  Компилировать код нужно с дополнительным параметром -lpthread:

  Запускаем и меняем значение переменной просто вводя новое значение в терминальном окне:

  Вместо заключения

  В следующих статьях я хочу рассмотреть технологии d-bus и RPC. Если есть интерес, дайте знать.
  Спасибо.

  UPD: Обновил 3-ю главу про семафоры. Добавил подглаву про мьютекс.

  Источник

  Читайте также:  Аппаратное шифрование ssd linux