2010-10-15 2 views
0

У меня есть хорошее назначение программирования ядра, включающее новый метод блокировки ядра, и моя группа и я решили реализовать его как оболочку вокруг завершения. Однако спецификация требует, чтобы мы возвращали количество процессов, уведомленных нашим методом, что включало возвращение количества процессов, которые пробуждались complete_all в нашей реализации.Есть ли какой-либо безопасный способ получить количество задач, ожидающих в настоящее время при завершении?

Как мы можем получить этот номер? Казалось бы, достаточно зафиксировать завершение своей внутренней спин-блокировкой, подсчитать количество элементов и затем разблокировать ее. Этот метод является безопасным, поскольку наши функции являются единственными, кто имеет доступ к конкретному завершению.

Итак, вопрос в том, является ли конструкция завершением непрозрачной? Если это так, приемлемо ли было бы для того, чтобы наша домашняя работа была сделана вовремя для промежуточного сезона, игнорировать эту непрозрачность? Или, есть ли способ сделать это без хаков?

ответ

1

Строго говоря, это непрозрачно, т.е. он определен в заголовке, но вы это знали.

Возможно, автору было бы непрозрачно, но оно было продано для публичного определения, чтобы позволить статическим встроенным линиям работать на нем. Это довольно часто встречается в коде ядра, потому что вас больше беспокоит скорость &, а размер кода меньше, чем строгий API. В любом случае, это все код ядра.

Я вижу:

struct completion { 
     unsigned int done; 
     wait_queue_head_t wait; 
}; 

Так что большинство интересных бит на самом деле в wait_queue_head_t, который является ЬурейеЙ из struct __wait_queue_head.

Двойные подчеркивания могут указывать на то, что автор считает, что это личное, или они просто подумали, что было бы странно иметь struct wait_queue_head и wait_queue_head_t, т.е. двойные подчеркивания дают понять, что вы собираетесь использовать typedef.

Я думаю, что вы смотрите на это неправильно. Вы сказали, что вам нужно знать количество процессов, разбуженных на complete_all(). Этот код уже берет блокировку и просматривает список процессов, которые нужно проснуться, т.е. чтобы разбудить их, так почему бы ему не вернуть число процессов, которые проснулись?

+0

Не complete_all просто пробуждает все процессы? Я вообще не хожу по списку процессов, я просто звоню в full_all и позволяю ему делать это. – Alex

+1

Да complete_all() пробуждает все процессы, и при этом он должен знать, сколько всего «всего», и оно может вернуть это вам. Кто-то может возразить, что это взломать, но я думаю, что это разумное решение, и это чище, чем просто переходить в список, чтобы получить счет. – mpe

2

Вы можете просто хотеть изменить __wake_up_common так, чтобы он возвращал количество просчитанных задач, а затем изменил complete_all, чтобы вернуть это же число.

Удачи с телефоном вверх и вниз.

Кстати, непрозрачная структура будет иметь typedef struct whatever whatever_t, например atomic_t. Они непрозрачны.

Nico.

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