help. C.

Кажется, тебе нужно использовать pthread_once()

вносите царя

Хм, кому-то нравится читать весь этот поток брани?

Так это вроде для того, чтобы ключ создался один раз, к мьютексам это отношения не имеет вроде

тот поток, которые раньше всех выполнил pthread_mutex_init

А вы таки один и тот же мьютекс из разных потоков инициализируете?

Нет, он инициализирован уже. Прошу прощения, перепутал с pthread_mutex_lock(опечатался).

Ну а в чём вопрос тогда? Если N потоков пытаются заблокировать мьютекс, о какой гонке идет речь?

Если же вопрос о том, в какой последовательности будут разблокироваться спящие на мьютексе потоки после его освобождения, насколько я помню, этот порядок не определён - т.е. не гарантируется, что потоки проснутся на мьютексе в том порядке, в котором заснули, если их там больше 1. Опять же, насколько я помню, когда-то это гарантировалось, но потом от этого отказались.

А зачем это может быть нужно?

pthread_mutexattr_setprioceiling не то?

Ну в ситуации, когда 2 потока(или более) выполнили pthread_mutex_lock на уже заблокированный мьютекс как только блокировка будет снята контроль получит тот поток, которые успеет заблокировать первым, не факт, что это будет тот, которые раньше выполнил pthread_mutex_lock, разве не так?

PTHREAD_PRIO_INHERIT в pthread_mutexattr_setprotocol вполне может помочь разрулить доступ к мьютексу по приоритетам. Насколько помню делаем для потоков SCHED_FIFO, ставим приоритеты, для мьютекса выставляем PTHREAD_PRIO_INHERIT и вуаля - лочить мьютекс потоки будут по приоритетам.Хотя я могу и ошибаться - подобной черной магией я давно уже не занимался.

pthread_once() нужна для того, чтобы выполнить функцию один раз. К изначальному вопросу про pthread_mutex_init() из нескольких потоков этот ответ вполне подходит.

Вот и я о том же, что не гарантируется, думал, может есть какие-то стандартные средства, интересно стало.

не факт, что это будет тот, которые раньше выполнил pthread_mutex_lock, разве не так?

Почему тебя вообще волнует порядок разблокировки?

<тыча пальцем в небо> Возможно ТС хочет изобрести shared/exclusive lock

Хм, кому-то нравится читать весь этот поток брани?

Дело в том, что всё познаётся в сравнении. Люди смотрят на эту исполненную запредельного чсв анскилльную лалку, и сами растут в своих глазах.

А-а-а, ну тогда пусть приходит. Я разрешаю.

ТС очередь ожидания что ли хочет изобрести?

Скорее от priority inversion пытается избавиться.

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

Другое дело - зачем это нужно? Я не вижу смысла. Возможно, тут уже архитектуру стоит пересмотреть.

анскилльную лалку

пополнил тезаурус дважды в теме, благодарю, беру на вооружение :)

Тут нет практической цели, просто вдруг стало интересно как сделать так, чтобы первый, кто выполнил lock, получил контроль первым, как только мьютекс освободится.

Тут нет практической цели, просто вдруг стало интересно

Лучше почитай что такое этот самый мутекс и как он работает. сразу такие глупости перестанешь спрашивать.

Ты как будто тредов царя не читал

кстати где он? захерел говорят...

А что тут глупого? Мне вот стало интересно, а ответа в литературе не нашел. Если я где-то ляпнул глупость, вразуми, а не просто какашку кинь.

http://wwwasd.web.cern.ch/wwwasd/lhc /ObjectSpace/doc/pro/foundusr/thread.4....

смотри fifo_mutex.

Спасибо.

Кто таков, чем знаменит?

Да не за что. Оно правда старое, закрытое и так далее. Но общая идея должна быть ясна.

Производительность; илитный запил оптимальных реализаций и основы матчасти.

а в чём там priority inversion? не слова же о приоритетах не было?

Я так понял он хочет чтобы определенный поток захватывал мьютекс с приоритетом перед остальными. По формулировке задачи до конца так и не ясно что же ему было нужно и я предположил что речь об priority inversion.

Не совсем, я просто хочу чтобы было так: если какой-то потом раньше других выполнил mutex_lock, он должен его и получить, когда мьютекс разблокируется.

поток*

Не знает, как быстро складывать числа.

Погугли «pthread mutex ticket lock» - вроде оно.

Уже прочитал про pthread_cond_t, это вроде оно и есть) спасибо

А если приоритеты равны у потоков, то они будут поочередно блокировать mutex?

mutex-ам я задал в параметре PTHREAD_PRIO_INHERIT, поставил приоритет у всех один и задал SCHED_FIFO. Запускаю 3 потока на 100 сообщений из очереди, так вот 1 из потоков(всегда разный) хватает >90 или около того.

B влияет ли изменение приоритета через pthread_setschedparam на гонку между потоками? т.е. если поставить потоку больший приоритет будет ли он выигрывать гонку?

http://www.opennet.ru/man.shtml?topic=sched_setscheduler&category=2&r... почитай, особенно про SCHED_FIFO.

Спасибо! То что надо.

pthread_yield и sched_yield оказывают маленький эффект или вообще не оказывают, может есть тонкость какая-то? не подскажешь?

Если треды с одинаковым приоритетом, то планироваться даже с FIFO они будут «случайно» и придется изобретать FIFO mutex. Постараюсь откопать код где уже решалась подобная проблема (интенсивный I/O с высоким приоритетом) - там вроде решилось без велосипедов.

Сейчас у меня нет цели сделать так, чтобы треды точно доуг за другом шли, мне надо, чтоб они примерно одинаково работали. По идее yield должен помочь, но все равно один поток захватывает управление постоянно. Я штуковину запилил с изменением приоритета потока после захвата сообщения из очереди, следующий поток возвращает предыдущему его приоритет. Но это костыль, ведь yield должен кидать поток в конец очереди потоков одинакового приоритета.

Заметил еще одну вещь, если я запускаю программу через valgrind, что pthread_yield работает прекрасно, а поднятие/опускание приоритета не помогает(доходит до того, что 2 из 3х потоков почти не активны), без valgrind все наоборот.

Попробуй SCHED_RR - если таски, которые выполняют потоки идентичны, то нагрузка должна равномерно по ним размазаться и без sched_yield().