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

dbase(void) { pthread_mutex_init(&loc, NULL); }

~dbase(void) { pthread_mutex_destroy(&loc); }

void add(const elements e) {

pthread_mutex_lock(&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_mutex_unlock(&loc);

}

int pos(const elements e) {

int n = 0;

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

В случае успешного завершения функция возвращает нулевое значение, в противном случае — один из следующих кодов ошибок:

AGAIN— системе не хватает ресурсов для инициализации блокировки;

EBUSY— объект крутящейся блокировки, на который указывает spinner, уже инициирован;

EINVAL— некорректный объект spinner;

ENOMEM— система не имеет достаточного количества свободной памяти для создания нового объекта.

int pthread_spin_destroy(pthread_spinlock_t* spinner);

Функция деинициализирует объект крутящейся блокировки. После деинициализации для последующего применения объекта он должен быть вновь инициализирован. Обратите внимание, результат функции не определен, если поток в данный момент крутится на блокировке, на которую указывает spinner, либо если объект spinnerне был инициализирован.

Возвращаемые значения:

EOK— успешное выполнение;

EBUSY— блокировка используется другим потоком и не может быть разрушена;

EINVAL— некорректный объект spinner.

int pthread_spin_lock(pthread_spinlock_t* spinner);

int pthread_spin_trylock(pthread_spinlock_t* spinner);

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

Попытка повторного захвата крутящейся блокировки из того же потока приводит к мертвой блокировке.