LINUX.ORG.RU

Гм, а что такое "fast" mutex? Или я что-то не понимаю?
Так или иначе, библиотека linuxthreads переопределяет сигнальные
функции, так что по идее ничего плохого не должно случиться. Если
обработчик сигнала написан правильно, тред продолжит сидеть на
этом мутексе.

jek_
()
Ответ на: комментарий от jek_

В man pthread_mutex_lock написано "the mutex kind, which is either ``fast'', ``recursive'', or ``error checking''." Может у меня старый ман?

А по поводу сигнала потоку блокированному на мутексе, меня интересовало примерно следующее --- если тред продолжит сидеть на мутексе, то сигнал доставится позже, когда мутекс освободится или сигнал будет проигнорирован?

Где можно посмотреть как правильно писать обработчики сигналов в многопоточных приложениях для LinuxThreads, которые в части обработки сигналов сильно? А то блин, есть желание не пользоваться pthread_create() и все подобное, а пользовать clone(), там хоть все понятно, есть флаг CLONE_SIGHAND.

И еще вопрос, что быстрее pthread_mutex или IPC semaphore? Ведь pthread_mutex реализуются через отдельный процесс (поток), а IPC это просто syscall.

mky ★★★★★
() автор топика
Ответ на: комментарий от mky

Сорри, мой косяк - забыл про fast мутексы. Но в данном случае тип
мутекса отношения к делу не имеет. Если поток сидит на локе и ему
приходит сигнал, то, если обратотчик написан правильно, он обработается,
и поток останется сидеть на своем локе. Если, пока поток был в
обработчике, лок отпустился, поток снимется с этого мутекса как только
завершится обработчик.

Замечательный документ про сигналы можно почитать здесь:
http://www.google.ru/groups?dq=&hl=ru&lr=&ie=UTF-8&oe=UTF-8&
threadm=200404270542.i3R5gTuF010529%40segfault.kiev.ua&prev=/groups%3Fdq%3D%
26num%3D25%26hl%3Dru%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26group%3Dfido7.ru.unix.p
rog%26start%3D25

Но! LinuxThreads - это особый случай. Эта библиотека терпеть не может
сигналы, посколько ее кишки сделаны именно на их основе. Так что 
нужно быть вдвойне (или даже больше) быть осторожным, используя сигналы
с LinuxThreads.

Вот только я не совсем понял утвердение, что "pthread_mutex
реализуются через отдельный процесс". Как это? Все эти функции
реализуются на основе сигнального механизма с использованием ОДНОГО
дополнительного менеджер-треда.

jek_
()
Ответ на: комментарий от jek_

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

А про LinuxThreads все терзаю сомнения, залазить в исходики glibc нет особого желания, а дока там помечена 2001 годом... :(

>Вот только я не совсем понял утвердение, что "pthread_mutex реализуются через отдельный процесс". Как это? Все эти функции реализуются на основе сигнального механизма с использованием ОДНОГО дополнительного менеджер-треда.

Да, менеджер-треда, просто вроде под Linux'ом было мало различий между потоком и процессом на уровне ядра. Мне и хотелось бы узнать сколько происходит системных вызовов и переключений контеста процесса при вызове pthread_mutex. И еще возник вопрос, можно ли использовать IPC семафор для синхронизации потоков(нитей, тредов) одного процесса?

mky ★★★★★
() автор топика
Ответ на: комментарий от mky

Я не знаю, сколько происходит сисколлов и переключеный контекста.
pthread_mutex_lock просто делает некоторые-то проверки и в случае
залочивания садится в sigwait на какой-то выделенный restart_signal.
Когда кто-то его разлочивает, менеджер бросает ему restart_signal, тред
отпускается. Только и всего. 

Насчет IPC семафора - наверно можно. Почему бы нет?.. Хотя лично у меня
опыта в IPC нет. Треды в LinuxThreads это действительно легковесные
процессы. Конечно, программа, делающая такое предположение,
автоматически делается непортабельной и скорее всего не будет работать
на том же NPTL. 

jek_
()
Ответ на: комментарий от mky

Если под IPC ты имеешь в виду System V IPC, то это средства разделяемой памяти и синхронизации между процессами, а не тредами. Вот, например, Oracle -- многопроцессный, и использует SysV IPC. А MySQL многопоточный, и использует POSIX Threads.

iliyap ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.