Встроенные системы: разработка API, который отслеживает адрес

Question

Этот вопрос был брошен в качестве отправной точки в техническом интервью в полупроводниковой компании. Я думаю, что нет правильного ответа - цель этого открытого вопроса состоит в том, чтобы измерить глубину и уровень комфорта инженера. Вопрос: - разработать API, который отслеживает адрес и возвращает его, когда адрес содержит определенное значение: -

void reach_target_value(volatile int* addr, int value);

Мое наивное решение было примерно таким: -

void reach_target_value(volatile int* addr, int value)
{
  while(*addr != value)
  {
    //Do nothing - spin in a tight loop
  }
}

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

Answer 1

Это действительно вопрос, на который (как вы предположили) можно ответить как можно шире.Вопрос с этим вопросом для собеседования - не ваш ответ (с учетом полученных вами предварительных условий, вы все равно не можете ответить на него), а скорее ваши уточняющие вопросы: есть ли у вас методология и навыки, чтобы отследить проблему, окружив ее все более подробными вопросами?.

Возможные ответы варьируются от вашего «наивного» подхода ожидания с занятостью, который может быть вполне допустимым решением, например, в AVR Tiny, который ожидает прерывания и которому больше нечего делать, кромеиспользование задачи таймера для частого отслеживания изменений при использовании mprotect во встроенной системе Linux для отслеживания переменной «на оборудовании» и получения сигнала, как только какой-то код записывает в эту память (и множество других подходовпроблема).

Что такое «правильный способ» ведения дел, зависит от большого количества предварительных условий, которые ваш интервьюер действительно ожидал, что вы спросите, (и без ответов на эти вопросы нет никакого возможного путиответить) как

• Мы говорим о голом металле или есть ОСРВ, может быть, даже встроенный Linux или Windows?
• Если голый металл, возможно, мы работаем в среде, которая поддерживает наблюдение за изменениями памяти (некоторые ARMвстроенные процессоры имеют)?
• Есть ли у system какие-либо другие задачи, пока она ожидает изменения памяти?
• Есть ли у нас таймеры, и если да, как частоожидается, что переменная изменится (т. е. насколько велика вероятность того, что мы можем пропустить изменение, если мы используем подход с таймером, и каковы минимальные ожидания реакции на изменение, разрешено ли нам пропускать изменения)?
• Работаем ли мы в среде виртуальной памяти, поддерживающей ошибки страниц, которые могут помочь нам через mprotect?По теме: Есть ли у нас какое-либо оборудование, которое могло бы помочь нам, например, поддержка MMU или аппаратной точки наблюдения?
• В случае, если у нас есть несколько потоков, ожидающих изменения, сколько их, это постоянное число, которое мызнаете раньше, или потребители меняются со временем?
• Как записывает в адрес памяти, синхронизированный между задачами, которые его изменяют?Можем ли мы ограничить доступ мьютексами или аналогичными средствами?
• ....

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

Answer 2

Я думаю, что повторная проверка в цикле не очень хороший дизайн.

На самом деле, этот вопрос имеет ту же техническую точку со следующим: Смотреть местоположение в памяти / устанавливать «точку останова данных» из кода?

Когда вы обнаружили изменения в памяти, самое время проверить значение и определить, возвращать ли его.