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

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

5 голосов
/ 08 февраля 2010

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

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

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

Update0

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

Update1

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

Ответы [ 4 ]

2 голосов
/ 30 мая 2010

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

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

и Хелгринд

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

Хелгринд знает обо всем этом абстракции и отслеживает их эффекты настолько точно, насколько это возможно. На х86 и платформы amd64, он понимает и частично обрабатывает неявную блокировку вытекающие из использования ЗАМКА префикс инструкции.

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

2 голосов
/ 08 февраля 2010

стадо - еще один хороший

0 голосов
/ 29 мая 2010

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

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

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

Так что нет никакого "общего" способа отследить их.

0 голосов
/ 10 февраля 2010

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

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 должны быть проверены.

...