Олег Цилюрик - QNX/UNIX - Анатомия параллелизма

pthread_mutex_lock(&loc);

for (list::iterator i = begin(); i != end(); i++, n++)

if (*i == e) {

delay(READ_DELAY);

break;

}

pthread_mutex_unlock(&loc);

if (n == size()) n = -1;

return n;

}

} data;

А в вызывающей программе цикл запросов к данным преобразуем в:

pthread_t *h = new pthread_t[n];

uint64_t t = ClockCycles();

for (int i = 0; i < n; i++) {

element e = erand(n);

pthread_create(h + i, NULL, wrand(p) ? add : pos, (void*)e);

}

for (int i = 0; i < n; i++)

pthread_join(h[i], NULL);

t = ((ClockCycles() - t) * 1000000000) / cps;

delete h;

А используемые этим фрагментом функции потоков определим как:

static void* add(void* par) { data.add((element)par); }

static void* pos(void* par) { data.pos((element)par); }

Совершенно естественно, что список элементов, из которого мы извлекаем данные (и куда изредка помещаем новые), должен защищаться как при модификации, так и при считывании (во избежание их одновременной модификации «со стороны»). Понятно, что в представленном решении мы чересчур перестраховались: во время считывания мы должны защищаться от потенциальной одновременной модификации, но нет необходимости защищать структуру данных от параллельного считывания. Поэтому переопределим структуру данных ( файл sy12.cc ), используя блокировку чтения/записи, оставив все прочее без изменений:

class dbase : public list {

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::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::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— доступ к объекту синхронизации возможен только для потоков процесса, из адресного пространства которого была распределена память объекта синхронизации.