Наверху pthread взаимных исключений?

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

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

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

Это немного не по теме, но вы, кажется, новичок в многопоточности - с одной стороны, блокируйте только там, где потоки могут перекрываться. Затем постарайтесь свести к минимуму эти места. Кроме того, вместо того, чтобы пытаться заблокировать каждый метод, подумайте о том, что поток (в целом) делает с объектом, сделайте это одним вызовом и заблокируйте его. Постарайтесь поднять свои блокировки как можно выше (это снова увеличивает эффективность и может / помочь / избежать взаимоблокировки). Но блокировки не «составляют», вы должны мысленно, по крайней мере, организовать свой код в зависимости от того, где находятся потоки и где они перекрываются.

Я создал аналогичную библиотеку, и у меня не было проблем с производительностью блокировки. (Я не могу точно сказать, как они реализованы, поэтому я не могу окончательно сказать, что это не имеет большого значения.)

Я бы сначала сделал все правильно (то есть использовал блокировки), а затем беспокоился о производительности . Я не знаю лучшего способа; для этого были созданы мьютексы.

Альтернативой для однопоточных клиентов было бы использование препроцессора для создания неблокированной и заблокированной версии вашей библиотеки. Например:

#ifdef BUILD_SINGLE_THREAD
    inline void lock () {}
    inline void unlock () {}
#else
    inline void lock () { doSomethingReal(); }
    inline void unlock () { doSomethingElseReal(); }
#endif

Конечно, это добавляет дополнительную сборку для обслуживания, поскольку вы будете распространять как однопоточные, так и многопоточные версии.

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

Однако .. linux - это совсем другое чудовище по сравнению с блокировкой нескольких процессов. Я знаю, что мьютекс реализуется с использованием атомарных инструкций ЦП и применяется только к процессу - поэтому они будут иметь такую ​​же производительность, что и критическая секция win32, то есть будут очень быстрыми.

Конечно, самая быстрая блокировка - это не иметь любые вообще или использовать их как можно реже (но если ваша библиотека будет использоваться в многопоточной среде, вам нужно заблокировать как можно более короткое время: заблокировать, сделать что-то, разблокировать,

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

Во многих случаях вы можете использовать атомарные встроенные функции, если ваш компилятор предоставляет их (если вы используете gcc или icc __sync_fetch * () и т.п.), но с ними, как правило, трудно правильно обращаться.

Если вы можете гарантировать, что доступ будет атомарным (например, на x86 чтение или запись двойного слова всегда атомарен, если он выровнен, но не чтение-изменение-запись), вы часто можете вообще избежать блокировок и вместо этого использовать volatile, но это непереносимо и требует знания оборудования.

Я думаю, что функция импорта проектов есть только в последней стабильной разработке плагина m2e.

Вот самый простой способ, который я нашел, чтобы сделать то, что вы описываете:

1. Проверьте где-нибудь все репозиторий svn, включая весь исходный код (для этого я использую TortoiseSVN) Затем используйте параметр compiler / makefile для включения / отключения потоковой передачи.

   Пр.

   #ifdef THREAD_ENABLED
   #define pthread_mutex_lock(x) ... //actual mutex call
   #endif
   
   #ifndef THREAD_ENABLED
   #define pthread_mutex_lock(x) ... //do nothing
   #endif
   

   Затем при компиляции выполните gcc -DTHREAD_ENABLED для включения потоковой передачи.

   Опять же, я бы НЕ использовал этот метод в любом большом проекте. Но только если вам нужно что-то довольно простое.

Мьютекс требует переключения контекста ОС. Это довольно дорого. ЦП по-прежнему может делать это сотни тысяч раз в секунду без особых проблем, но это намного дороже, чем без мьютекса. Вводить его в каждый доступ к переменной, вероятно, будет излишним.

Это также, вероятно, не то, что вам нужно. Этот вид блокировки грубой силой имеет тенденцию приводить к взаимоблокировкам.

знаете ли вы лучшие способы защиты доступа к таким переменным?

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

Мне было интересно узнать о расходах на использование pthred_mutex_lock / unlock . У меня был сценарий, в котором мне нужно было скопировать где-нибудь от 1500-65K байт без использования мьютекс или использовать мьютекс и выполнить однократную запись указателя на необходимые данные.

Я написал короткий цикл для проверки каждого

gettimeofday(&starttime, NULL)
COPY DATA
gettimeofday(&endtime, NULL)
timersub(&endtime, &starttime, &timediff)
print out timediff data

или

ettimeofday(&starttime, NULL)
pthread_mutex_lock(&mutex);
gettimeofday(&endtime, NULL)
pthread_mutex_unlock(&mutex);
timersub(&endtime, &starttime, &timediff)
print out timediff data

. Если я копировал менее 4000 или около того байтов, то операция прямого копирования занимала меньше времени. Если, однако, я копировал более 4000 байт, то блокировка / разблокировка мьютекса обходилась дешевле.

Время блокировки / разблокировки мьютекса составляло от 3 до 5 мкс, включая время для gettimeofday для currentTime, что заняло около 2 мкс