Проверьте, заблокирована ли нить pthread

Вот ситуация, у меня есть поток, который частично контролируется кодом, который у меня нет. Я начал поток, поэтому у меня есть его идентификатор потока, но затем я передал его другому коде. Мне нужно узнать, не вызвал ли этот другой код поток, который блокируется из другого потока, которым я управляю. Есть ли способ сделать это в pthreads? Я думаю, что я ищу что-то, что эквивалентно методу getState() в классе Thread Java (http://download.oracle.com/javase/6/docs/api/java/lang/Thread.html#getState()) ,Проверьте, заблокирована ли нить pthread

-------------- Edit -----------------

Это нормально, если решение зависит от платформы. Я уже нашел решение для linux с помощью файловой системы/proc.

источник

2011-09-22 Kurtis Nusbaum

Что вы на самом деле пытаетесь достичь? Могут быть другие/лучшие способы, чем пытаться имитировать java. – Duck

Это для рамки тестирования. Мы пытаемся контролировать расписание потоков, чтобы люди могли тестировать реентер-код в явно определенных графиках потоков. –

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

Конечно, это только говорит вам, когда они заблокированы на объектах синхронизации pthreads - это не скажет вам, когда они блокируют что-то еще.

источник

2011-09-27 22:05:12 Dmitri

Это действительно хорошо, и я, вероятно, буду делать что-то подобное. Как вы думаете, есть ли способ выяснить, блокируют ли они что-то еще, например I/O? –

Я думаю, что способ сделать это может зависеть от того, что они блокируют. Если вы можете сказать, что они неактивны и не заблокированы на pthreads, можно с уверенностью сказать, что они ждут чего-то еще ... но выяснение того, что может быть сложным.Я не заглядывал в это достаточно, чтобы сказать многое наверняка. – Dmitri

-1

Прежде чем передать поток в какой-либо другой код, установите флаг, защищенный мьютексом. Когда поток возвращается из кода, который вы не контролируете, очистите флаг, защищенный мьютексом. Затем вы можете проверить, где бы вы ни находились, является ли поток в коде, который вы не контролируете.

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

Например, рассмотрите две реализации библиотеки.

A: Мы выполняем всю работу в вызывающей нити.

B: Мы отправляем рабочий поток для выполнения работы. Вызывающий поток блокируется до тех пор, пока рабочий не будет выполнен.

В обоих случаях A и B код, который вы не контролируете, в равной мере продвигает вперед. Идея «getstate» обеспечит разные результаты. Так что это не то, что вы хотите.

источник

2011-09-22 23:42:59

Это не работает, потому что состояние потоков (блокировка или разблокировка) может измениться, прежде чем я снова получу контроль над ним. –

Конечно, но зачем вас это волнует? Если вы хотите проверить, продолжает ли операция через минуту (возможно, чтобы решить ее отменить или перейти), вам все равно, если это произойдет, чтобы закончить раскол секунды после проверки. Как только вы решите, что прошло достаточно времени, и вы определили, что он все еще продолжается, вы должны безотзывно решить отказаться. У вас будет такая же ситуация с «getstate», о которой вы спрашивали. –

Для чего мне все равно, пожалуйста, посмотрите комментарий, который я сделал для оригинального вопроса. –

Проверьте, заблокирована ли нить pthread

ответ

Смежные вопросы