Какие вызовы межпроцессорной блокировки я должен отслеживать?

Question

Я наблюдаю за процессом с strace/ltrace в надежде найти и перехватить вызов, который проверяет и потенциально активирует какую-то глобальную общую блокировку.

Хотя я уже имел дело с несколькими формами межпроцессорной блокировки в Linux и читал о них ранее, я не обращаю внимания на то, что нужно искать в вызовах.

В настоящее время мой единственный подозреваемый futex() который появляется очень рано в процессе выполнения.

Update0

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

Update1

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

Answer 1

Если вы можете запустить отслеживаемый процесс в valgrind, то есть два проекта:

http://code.google.com/p/data-race-test/wiki/ThreadSanitizer

и Хельгринд

http://valgrind.org/docs/manual/hg-manual.html

Хелгринд знает обо всех абстракциях pthread и отслеживает их эффекты с максимальной точностью. На платформах x86 и amd64 он понимает и частично обрабатывает неявную блокировку, возникающую из-за использования префикса инструкции LOCK.

Таким образом, эти инструменты могут обнаружить даже атомарный доступ к памяти. И они будут проверять использование

Answer 2

Стая это еще один хороший

Answer 3

1. Для блокировки можно использовать множество системных вызовов: flock, fcntl и даже create.

2. Когда вы используете блокировки pthreads/sem_*, они могут выполняться в пользовательском пространстве, поэтому вы никогда не увидите их в strace, поскольку futex вызывается только для ожидающих операций. Например, когда вам действительно нужно ждать.

3. Некоторые операции могут быть выполнены только в пользовательском пространстве - например, спин-блокировки - вы их никогда не увидите, если они не ждут таймера - откат, поэтому вы можете видеть только такие вещи, как nanosleep, когда одна блокировка ожидает другую.

Таким образом, нет никакого "общего" способа отследить их.

Answer 4

В системах с glibc ~ >= 2.5 (glibc + nptl) вы можете использовать процесс shared

semaphores (last parameter to sem_init), more precisely, posix unnamed semaphores

posix mutexes (with PTHREAD_PROCESS_SHARED to pthread_mutexattr_setpshared)

posix named semaphores (got from sem_open/sem_unlink)

system v (sysv) semaphores: semget, semop

В старых системах с glibc 2.2, 2.3 с linuxthreads или во встроенных системах с uClibc вы можете использовать ТОЛЬКО семафоры system v (sysv) для обмена данными между процессами.

upd1: любой IPC и socker должны быть проверены.