pthread_create(NULL, &attr, &ThreadProc, strdup(data));
}
2. Для передачи параметра скалярного типа (char, short, int), не превышающего размер указателя, очень часто в самых разнообразных источниках [1, 3] можно увидеть такой трюк, когда указателю присваивается непосредственное значение скалярной величины:
// функция потока:
void* ThreadProc(void* data) {
// ... выполняется обработка, используя значение параметра (char)data
return NULL;
}
// порождающий потоки код:
while (true) {
char data = /* инициализация параметра */;
if ( /* ожидаем нечто */ )
pthread_create(NULL, &attr, &ThreadProc, (void*)data);
}
Или даже так:
pthread_create(NULL, &attr, &ThreadProc, (void*)5);
pthread_create(NULL, &attr, &ThreadProc, (void*)(x + y));
Положительной стороной этого решения (которое тем не менее остается трюкачеством) является то, что параметр в ThreadProc() передается по значению, то есть неявным копированием, и любые последующие манипуляции с ним не приведут к порче переданного значения. Таким образом, в ThreadProc() нет необходимости создавать локальную копию полученного параметра.
3. Создание экземпляра данных в родительском потоке для каждого нового экземпляра создаваемого потока с гарантированным уничтожением экземпляра данных при завершении порожденного потока:
void* ThreadProc(void *data) {
// используем экземпляр data без копирования ...
...
delete data;
return NULL;
}
...
if ( /* нечто */ ) {
// создание экземпляра вместе с инициализацией
// (предполагаем, что для DataParam ранее определен
// копирующий конструктор):
pthread_create(NULL, &attr, &ThreadProc, new DataParam(data));
}
Это один из самых безошибочно срабатывающих способов, и единственным его недостатком является то, что объекты создаются в одной структурной единице (родителе), а уничтожаться должны в другой (потомке), которые иногда даже размещаются в различных файлах программного кода, а ошибки с парностью операций над динамической памятью обходятся очень дорого.
4. "Ручной" вызов диспетчеризации в порождающем потоке, по крайней мере при дисциплине по умолчанию для QNX - round-robin:
if ( /* нечто */ ) {
pthread_create(NULL, &attr, &ThreadProc, &data);
sched_yield();
}
Мы не можем произвольно изменять последовательность выполнения потоков (чем нарушили бы принципы диспетчеризации) и не можем утверждать, что при наличии многих потоков именно только что порожденный поток получит управление. Но после выполнения sched_yield() мы можем гарантировать, что родительский поток будет помещен именно в хвост очереди потоков равных приоритетов, готовых к исполнению, и его активизация произойдет позже всех наличных в системе потоков, в том числе и последнего порожденного.
Примечание
В этом месте внимательный читатель вправе оживиться: "Обманывают, обвешивают…". Да, описываемое здесь экзотическое решение не совсем корректно с позиции уже упоминавшегося определения Э. Дейкстры "слабосвязанных процессов" и независимости результата от относительных скоростей: в SMP-системе при количестве процессоров, большем, чем количество параллельных потоков, это решение не будет работать так, как мы ему предписываем. Но к настоящему времени такое "стечение обстоятельств" может быть либо чисто теоретически умозрительным, либо возникать на экспериментальных единичных образцах SMP, содержащих десятки и сотни процессоров…, но где QNX, насколько нам известно, не используется.
В этом варианте и в порожденном потоке можно симметрично сделать так:
void* ThreadProc(void *data) {
struct DataParam copy(*data);
sched_yield();
...
}
Примечание
Иногда для выражения этой техники используется и такая, в общем несколько небрежная, форма записи:
pthread_create(NULL, &attr, &ThreadProc, &data);
delay(1); // вместо sched_yield()
Фокус здесь состоит не в том, что 1 миллисекунда - это время, заведомо достаточное для копирования экземпляра данных, а в том, что POSIX определяет, что операция delay() (а также все родственные ей функции: sleep(), nanosleep() и другие функции пассивной задержки) является операцией пассивного ожидания и должна сопровождаться принудительной диспетчеризацией.
5. Создание потока с приоритетом выше, чем родительский, с последующим возвратом его приоритета на прежний уровень после выполнения требуемой инициализации копии:
void* ThreadProc(void* data) {
struct sched_param param;
int policy;
pthread_getschedparam(pthread_self(), &policy, ¶m);
param.sched_priority -= 2;
// инициализация копии блока данных
...
pthread_setschedparam(pthread_self(), policy, ¶m);
...
return NULL;
}
...
if ( /* нечто */ ) {
pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED);
pthread_attr_setschedpolicy(&attr, SCHED_RR);
int policy;
struct sched_param param;
pthread_getschedparam(pthread_self(), &policy, ¶m);
attr.param.sched_priority = param.sched_priority + 2;
pthread_create(NULL, &attr, &ThreadProc, &data);
}
Здесь в точке создания порожденный поток сразу же вытесняет своего родителя и выполняет инициализацию копии области параметров, после чего возвращается к нормальной (с равными приоритетами) диспетчеризации. Этот вариант может показаться искусственно усложненным, но отлично вписывается своими побочными достоинствами в создание многопоточных GUI-приложений для графической подсистемы Photon.
Данные потока
В реальном коде часто возникает ситуация, когда одновременно исполняются несколько экземпляров потоков, использующих один и тот же код (при создании потоков указывается одна и та же функция потока). При этом некоторые данные (например, статические объекты, глобальные объекты программного файла, объявленные вне функции потока) будут представлены для различных экземпляров потока в виде единого экземпляра данных, а другие (блок параметров функции потока, локальные данные функции потока) будут представлять собой индивидуальные экземпляры для каждого потока:
class DataBlock {
DataBlock(void);
DataBlock(DataBlock&);
}
DataBlock A;
void* ThreadProc(void *data) {
static DataBlock B;
DataBlock C, D(*(DataBlock*)data);
...
delete data;
return NULL;
}
...
for(int i = 0; i < N; i++ ) {
DataBlock E;
// ... обработка и заполнение E ...
pthread_create(NULL, NULL, &ThreadProc, new DataBlock(E));
}