Совершенно естественно, что список элементов, из которого мы извлекаем данные (и куда изредка помещаем новые), должен защищаться как при модификации, так и при считывании (во избежание их одновременной модификации «со стороны»). Понятно, что в представленном решении мы чересчур перестраховались: во время считывания мы должны защищаться от потенциальной одновременной модификации, но нет необходимости защищать структуру данных от параллельного считывания. Поэтому переопределим структуру данных ( файл sy12.cc), используя блокировку чтения/записи, оставив все прочее без изменений:
class dbase : public list<element> {
static const int READ_DELAY = 1, WRITE_DELAY = 2;
pthread_rwlock_t loc;
public:
dbase(void) { pthread_rwlock_init(&loc, NULL); }
~dbase(void) { pthread_rwlock_destroy(&loc); }
void add(const elements e) {
pthread_rwlock_wrlock(&loc);
int pos = size * rand / RAND_MAX;
list<element>::iterator p = begin;
for (int i = 0; i < pos; i++) p++;
insert(p, e);
delay(WRITE_DELAY);
pthread_rwlock_unlock(&loc);
}
int pos(const elements e) {
int n = 0;
pthread_rwlock_rdlock(&loc);
for (list<element>::iterator i = begin; i != end; i++, n++)
if (*i == e) {
delay(READ_DELAY);
break;
}
pthread_rwlock_unlock(&loc);
if (n == size) n = -1;
return n;
}
} data;
А теперь пришло время сравнить варианты:
# nice -n-19 sy10 500 .2
evaluation time: 1.2296 sec.
# nice -n-19 sy11 500 .2
evaluation time: 1.24973 sec.
# nice -n-19 sy12 500 .2
evaluation time: 0.440904 sec.
При
«жесткой» блокировке мы не получаем никакого выигрыша за счет параллельного выполнения запросов к данным, а при использовании блокировки чтения/записи — 3-кратный выигрыш. Проделаем то же самое, но в условиях гораздо меньшей интенсивности обновления данных относительно общего потока запросов:
# nice -n-19 sy10 500 .02
evaluation time 0.989699 sec.
# nice -n-19 sy11 500 .02
evaluation time 0.98391 sec.
# nice -n-19 sy12 500 .02
evaluation time 0.0863443 sec.
Выигрыш становится более чем 10-кратным.
Показанные примеры ( sy10.cc, sy11.cc, sy12.cc) в высшей степени условны: картина происходящего будет существенно другой при замене пассивного ожидания (
delay
) на активные процессорные операции над данными, но общие тенденции сохраняются.
Спинлок
Спинлок, или «крутящаяся» блокировка, предназначен исключительно для применения в системах SMP (Symmetrical Multi-Processing), то есть в многопроцессорных системах. Поведение спинлока практически идентично классическому мьютексу, за единственным исключением — ожидающий поток не блокируется и не вытесняется. Не забывайте, речь идет о многопроцессорной системе! Основным назначением спинлока является задержка выполнения обработчиков прерываний, и предназначены они для исключения временных потерь, связанных с переключением контекстов.
Функции работы с «крутящейся» блокировкой объявлены в заголовочном файле
<рthread.h>
. Самих функций немного, и они имеют минимальные возможности по настройке. Спинлок не поддерживает тайм-ауты. Появление этого элемента синхронизации в QNX Neutrino связано с требованиями стандарта POSIX 1003.1j (draft).
Операции со спинлоком
Инициализация и разрушение спинлока
int pthread_spin_init(pthread_spinlock_t* spinner, int pshared);
Функция инициализирует объект синхронизации спинлока блокировки, на который указывает аргумент
spinner
, и устанавливает для него параметр доступа из других процессов в соответствии со значением переменной
pshared
. Эта переменная может принимать следующие значения:
•
PTHREAD_PROCESS_SHARED
— с объектом спинлок может оперировать поток любого процесса, имеющего доступ к памяти, в которой распределен объект спинлок;
•
PTHREAD_PROCESS_PRIVATE
— доступ к объекту синхронизации возможен только для потоков процесса, из адресного пространства которого была распределена память объекта синхронизации.