Должен ли я использовать Mutex ИЛИ критический раздел для Windows Mobile RIL

Question

Я использую Собственные интерфейсы интерфейса радиосвязи (RIL) в приложении Windows Mobile . В этом API возвращаемые значения / результаты большинства функций не возвращаются сразу, а передаются через функцию обратного вызова, которая передается в API RIL.

Некоторые примеры использования можно найти в Инструменты разработки XDA и Google Gears Геолокация API .

Мой вопрос заключается в том, что в этих двух примерах мьютекс используется для защиты данных вместо других объектов синхронизации.

Теперь, будет ли Critical Section работать нормально в случаях использования, описанных в обоих примерах? Какой поток или процесс будет фактически вызывать функции обратного вызова?

Изменить:
Мои данные доступны через мои коды только из моего процесса, но какой поток / процесс вызывает функции обратного вызова в RIL API? Я имею в виду, что я передал функцию обратного вызова в API RIL, но вызваны ли обратные вызовы из другого процесса? в этом случае это даст другое объяснение, почему образцы используют Mutex. Если RIL API фактически создает поток внутри моего процесса и вызывает мои функции обратного вызова, то я думаю, что Critical Section будет в порядке (и он быстрее, чем мьютекс).

Обновление:
У меня есть данные, которые (1) доступны для моих кодов из моего собственного процесса, а также (2) изменены из функции обратного вызова. Обратный вызов выполняется RIL API.

Мой вопрос: Какой поток / процесс вызывает функции обратного вызова в RIL API?

История до сих пор:
Я: Привет, мистер Рил, пожалуйста, поместите некоторые данные в мой офис (переменные a.k.a).
RIL: ОК, сэр. Я опубликую данные позже и сообщу вам, когда это будет сделано (я использовал событие здесь).

Для входа в мой офис требуется карта доступа. Если г-н РИЛ принадлежит к той же компании, что и я, г-н РИЛ может использовать свою собственную карту доступа для входа в мой офис (в моем случае это означает критический раздел). Если он из других компаний, мне нужно будет настроить для него карту доступа / визитку (в моем случае мне нужен мьютекс).

Если г-н РИЛ использует свою собственную карту доступа, это означает, что мне не нужно настраивать карту доступа / карту посетителя для него, а это значит, меньше проблем для меня. (т.е. критическая секция быстрее, чем мьютекс)

Проблема в том, что я только что встретил этого мистера Рила несколько дней назад, и я мало что о нем знаю. Я не знаю, если он из той же компании, что и я. Один из вариантов, например , упомянутый от nobugz , заключается в установке карты доступа для Mr RIL независимо от того, принадлежит ли Mr RIL к той же компании, что и я. Таким образом, мистер Рил гарантированно сможет войти в мой офис. (мои данные / переменные гарантированно безопасны)

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

Aha! Просто пришла идея при написании этого. Думаю, я просто спрошу мистера Рила, из какой он компании. Таким образом, мне не нужно настраивать для него карту доступа в будущем, если он окажется в той же компании, что и я. (то есть, поместите GetCurrentProcessId() и GetCurrentThreadId() в функцию обратного вызова)

Answer 1

Windows Mobile RIL обычно находится в device.exe (для WM6.x). Однако, когда ваш процесс вызывает RIL, ваш вызов проходит через прокси RIL.

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

Это означает, что ваш код может использовать объект CRITICAL_SECTION для обеспечения необходимой синхронизации / защиты.

Answer 2

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

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

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

Обновление: если они не делают что-то действительно необычное в RIL, обратный вызов будет происходить в вашем процессе, поэтому критическое должно быть адекватным. Если он изменяет ваши данные, это означает, что ваши данные отображаются и видны этому коду - это означает, что данные в данных в критическом разделе также будут отображаться и отображаться, и это будет работать. Критический раздел не работает, когда вы работаете с отдельными процессами, поэтому данные в одном не отображаются / не видны другому.

Answer 3

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

Answer 4

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