Какие межпроцессные вызовы блокировки я должен контролировать?
Я контролирую процесс с strace/ltrace в надежде найти и прервать вызов, который проверяет и потенциально активирует некоторую глобально коллективную блокировку.
В то время как я имел дело с и читал о нескольких формах межпроцессной блокировки на Linux прежде, я терплю неудачу на что к вызовам для поиска.
В настоящее время мой единственный подозреваемый futex() который подходит очень вначале в выполнении процесса.
Update0
Существует некоторый беспорядок о том, что я после. Я контролирую существующий процесс для вызовов к персистентной межпроцессной памяти или эквивалентный. Я хотел бы знать то, что система и библиотека называют для поиска. У меня нет вызова намерения они самого, так естественно futex() подойдет, я уверен, что многие библиотеки реализуют свои вызовы блокировки с точки зрения этого и т.д.
Update1
Я хотел бы список имен функций или ссылку на документацию, которую я должен контролировать в ltrace и strace уровни (и указывающий, который). Любой другой хороший совет о том, как отследить и определить местоположение глобальной блокировки в памяти, был бы большим.
4 ответа
Если вы можете запустить отслеживаемый процесс в valgrind, то есть два проекта:
http://code.google.com/p/data-race-test/wiki/ThreadSanitizer
и Helgrind
http://valgrind.org/docs/manual/hg-manual.html
Helgrind знает обо всех pthread абстракции и отслеживает их эффекты как можно точнее. На x86 и amd64, он понимает и частично обрабатывает неявную блокировку в результате использования ЗАМКА префикс инструкции.
Таким образом, этот инструмент может обнаруживать даже атомарные обращения к памяти. И они будут проверять использование pthread
в системах с 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) для взаимодействия с iterprocess.
upd1: нужно проверять любой IPC и сокер.
Для блокировки можно использовать множество системных вызовов: flock, fcntl и даже create.
Когда вы используете блокировки pthreads / sem_ *, они могут выполняться в пользовательском пространстве, поэтому вы никогда не увидеть их в strace, поскольку фьютекс вызывается только для незавершенных операций. Как когда ты на самом деле нужно подождать.
Некоторые операции можно выполнять только в пользовательском пространстве - например, спин-блокировки - вы их никогда не увидите. если они не ждут таймера - отсрочки, поэтому вы можете видеть только такие вещи, как nanosleep, когда одна блокировка ожидает другой.
Таким образом, не существует «универсального» способа их отследить.