Должен ли я использовать Mutex ИЛИ критический раздел для Windows Mobile RIL
Я использую собственные API-интерфейсы Radio Layer Interface (RIL) в приложении Windows Mobile. В этом API возвращаемые значения / результаты большинства функций не возвращаются сразу, а передаются через функцию обратного вызова, которая передается в RIL API.
Некоторые примеры использования можно найти в XDA Develompent Tools и Google Gears Geolocation API.
Мой вопрос заключается в том, что в этих двух примерах мьютекс используется для защиты данных вместо других объектов синхронизации.
Теперь, сработает ли критический раздел здесь в случаях использования, описанных в обоих примерах? Какой поток или процесс будет фактически вызывать функции обратного вызова?
Редактировать:
Мои данные доступны для моих кодов только из моего процесса, но какой поток / процесс вызывает функции обратного вызова в RIL API? Я имею в виду, что я передал функцию обратного вызова в API RIL, но вызваны ли обратные вызовы из другого процесса? в этом случае это даст другое объяснение, почему образцы используют Mutex. Если RIL API фактически создает поток внутри моего процесса и вызывает мои функции обратного вызова, то я думаю, что Critical Section будет в порядке (и это быстрее, чем мьютекс).
Обновить:
У меня есть данные, к которым (1) обращаются мои коды из моего собственного процесса, а также (2) измененные из обратного вызова функции. Обратный вызов выполняется RIL API.
Мой вопрос: какой поток / процесс вызывает функции обратного вызова в RIL API?
История до сих пор:
Я: Привет, мистер Рил, пожалуйста, поместите некоторые данные в мой офис (иначе переменные).
RIL: ОК, сэр. Я опубликую данные позже и сообщу вам, когда это будет сделано (я использовал событие здесь).
Карта доступа требуется для входа в мой офис. Если г-н RIL принадлежит к той же компании, что и я, г-н RIL может использовать свою собственную карту доступа для входа в мой офис (в моем случае это означает критический раздел). Если он из других компаний, мне нужно будет настроить для него карту доступа / визитную карточку (в моем случае мне нужен мьютекс).
Если г-н РИЛ использует свою собственную карту доступа, это означает, что мне не нужно настраивать карту доступа / карту посетителя для него, и это означает, что для меня меньше проблем. (т.е. критический раздел быстрее, чем мьютекс)
Проблема в том, что я только что встретил этого мистера Рила несколько дней назад, и я мало что о нем знаю. Я не знаю, если он из той же компании, что и я. Один из вариантов, упомянутых Hans Passant, - это установить карту доступа для Mr RIL независимо от того, принадлежит ли Mr RIL к той же компании, что и я. Таким образом, мистер Рил гарантированно сможет войти в мой офис. (мои данные / переменные гарантированно безопасны)
Прямо сейчас я использую мьютекс в своем коде (установите, возможно, избыточную карту доступа для Mr RIL).
Ага! Просто пришла идея при написании этого. Думаю, я просто спрошу мистера Рила, из какой он компании. Таким образом, мне не нужно настраивать карту доступа для него в будущем, если он окажется в той же компании, что и я. (т.е. положить GetCurrentProcessId() а также GetCurrentThreadId() в функции обратного вызова)
4 ответа
Windows Mobile RIL обычно находится в device.exe (для WM6.x). Однако, когда ваш процесс вызывает RIL, ваш вызов проходит через прокси RIL.
Прокси-сервер RIL связан с вашим процессом и находится в нем, а также обрабатывает все проблемы, связанные с границами процесса для вас (кроме того, это как минимум часть причины, по которой все структуры данных RIL должны быть упакованы в единый блок памяти известного размера). Внутри RIL Proxy создает поток, в котором выполняется ваш обратный вызов.
Это означает, что ваш код может использовать объект CRITICAL_SECTION для обеспечения необходимой синхронизации / защиты.
Смысл использования мьютекса в том, что вы не знаете, какой поток может сделать обратный вызов. Да, критический раздел тоже подойдет. Осторожность, неправильная оценка приводит к случайному и очень трудно диагностировать сбой.
Критический раздел - мьютекс. Критический раздел отличается от обычного мьютекса (по крайней мере, в первую очередь) одним способом: он специфичен для одного процесса, где мьютекс может использоваться в разных процессах.
Таким образом, в этом случае основной вопрос заключается именно в том, что вы защищаете - если данные внутри вашей программы не будут доступны для другого процесса, тогда критический раздел должен хорошо выполнить свою работу. Если вы защищаете что-то, что будет совместно использоваться двумя процессами, если пользователь будет запускать два экземпляра вашей программы одновременно, то вам, вероятно, понадобится мьютекс.
Изменить: Что касается необходимости использовать критический раздел для защиты того, что делает сам RIL, нет, это не нужно (или, по крайней мере, определенно не должно), не нужно. С мьютексом вы рассчитываете на то, что все процессы взаимодействуют, открывая мьютекс с тем же именем для управления доступом к общим ресурсам. Вы не можете рассчитывать на это, поэтому, если это необходимо, интерфейс полностью нарушен.
Обновление: если они не делают что-то действительно необычное в RIL, обратный вызов будет происходить в вашем процессе, поэтому критическое должно быть адекватным. Если он изменяет ваши данные, это означает, что ваши данные отображаются и видны этому коду - это означает, что данные в данных в критическом разделе также будут отображаться и отображаться, и это будет работать. Критический раздел не работает, когда вы работаете с отдельными процессами, поэтому данные в одном не отображаются / не видны другому.
Ну, еще одно отличие между мьютексом и критической секцией (конечно, реализациями для Windows) состоит в том, что критическая секция является реентерабельной - то есть один и тот же поток может получить критическую секцию дважды, не выпуская ее.