QNX/UNIX: Анатомия параллелизма
вернуться

Цилюрик Олег Иванович
Шрифт:

• Если при создании ключа не определять деструктор экземпляра данных потока

pthread_key_create(..., NULL)
, то при завершении потока над экземпляром его данных не будут выполняться никакие деструктивные действия и созданные потоками экземпляры данных будут существовать и после завершения потоков.

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

В коде (что гораздо нагляднее) это может выглядеть так (код с заметными упрощениями взят из реального завершенного проекта):

// описание экземпляра данных потока

struct throwndata {

...

};

static pthread_once_t once = PTHREAD_ONCE_INIT;

static pthread_key_t key;

void createkey(void) { pthread_key_create(&key, NULL); }

// STL-очередь, например указателей на экземпляры данных

queue<throwndata*> result;

// функция потока

void* GetBlock(void*) {

pthread_once(&once, createkey);

throwndata *td;

if ((td = (throwndata*)pthread_getspecific(key)) == NULL) {

td = new throwndata;

pthread_setspecific(key, (void*)td);

// вот он - альтернативный путь доступа:

result.push(td);

}

// далее идет плодотворная работа над блоком данных *td

// . . . . . . . . .

}

int main(int argc, char **argv) {

// . . . . . .

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

pthread_create(NULL, NULL, GetBlock, NULL);

// . . . . . . к этому времени потоки завершились;

// ни в коем случае нельзя помещать result.size

// непосредственно в параметр цикла!

int n = result.size;

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

throwndata *d = result.front;

// обработка очередного блока *d ...

result pop;

delete d;

}

return EXIT_SUCCESS;

}

Примечание

В предыдущих примерах кода мы указывали третий параметр

pthread_create
в виде
&GetBlock
(адреса функции потока), но в текущем примере мы сознательно записали
GetBlock
. И то и другое верно, ибо компилятор достаточно умен, чтобы при указании имени функции взять ее адрес.

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

Безопасность вызовов в потоковой среде

Рассмотрев «в первом приближении» технику собственных данных потоков, мы теперь готовы ответить на вопрос: «В чем же главное предназначение такой в общем-то достаточно громоздкой техники? И зачем для ее введения потребовалось специально расширять стандарты POSIX?» Самое прямое ее предназначение, помимо других «попутных» применений, которые были обсуждены ранее, — это общий механизм превращения существующей функции для однопотокового исполнения в функцию, безопасную (thread safe) в многопоточном окружении. Этот механизм предлагает единую (в смысле «единообразную», а не «единственно возможную») технологию для разработчиков библиотечных модулей.

Примечание

ОС QNX, заимствующая инструментарий GNU-технологии (gcc, make, …), предусматривает возможность построения как статически связываемых библиотек (имена файлов вида

xxx.a
), так и разделяемых или динамически связываемых (имена файлов вида
xxx.so
). Целесообразность последних при построении автономных и встраиваемых систем (на что главным образом и нацелена ОС QNX) достаточно сомнительна. Однако высказанное выше положение о построении реентерабельных программных единиц относится не только к библиотечным модулям (как статическим, так и динамическим) в традиционном понимании термина «библиотека», но и охватывает куда более широкий спектр возможных объектов и в той же мере относится и просто к любым наборам утилитных объектных модулей (вида
xxx.о
), разрабатываемых в ходе реализации под целевой программный проект.