caxapa.ru :: Разделение ресурса в двухпроцессорной системе.

Snaky (30.04.2011 16:39 - 01.05.2011 03:21, просмотров: 8648)

Разделение ресурса в двухпроцессорной системе. Дано Допустим есть система в которой 2 процессора и они делят общий ресурс. Пусть будет внешняя флэш-память, для определенности. П-1 работает в жестком риалтайме и использует эту память для записи информации. П-2 работает в мягком риалтайме, одна из основных задач - общение с юзером. Тоже имеет доступ к тому же ресурсу (может читать/стирать память по запросам). Дополнение П1 - рабочая лошадка. его задача давать стране угля и складировать во флеш. П1 - работает всегда, независимо от состояния П2. П2 - толстый проц (менеджер) - его задача продавать уголь юзеру со всеми свистелками-перделками и красивыми интерфейсами. т.к. он он очень толстый и жрущий (на нем крутится какая-нибудь OS типа Linux) и не нужен значительную часть времени, то он спит для экономии энергии. Но даже когда он проснулся и "продает уголь" он все равно не должен мешаться рабочему, который сладирует уголь, а забегать на склад утащить мешочек-другой только в свободное время. Вопрос Какие применяются типовые механизмы разрешения коллизий? В общих чертах понятно что П-1 и П-2 должны уметь общаться между собой и каким-то образом согласовывать действия, а в деталях? Кто разрешает/запрещает/прерывает (ну тут вроде однозначно)? Как восстанавливается прерванная сессия? Как каждый из процессоров узнает об изменениях сделанным другим? итд итп Вопрос скорее системно-методологического уровня, ни к чему конкретному не привязан. Флеш - не значит микросхема датафлеши, м.б. CF-Card или SSD например, неважно.

DRC придумали трусы

Ответить

- Я бы предложил схему "монитор". И выполнять монитор логичнее на П1 т.е. пусть "толстый" ходит через "работягу". - Cкpипaч(02.05.2011 17:37)
- А почему бы не сделать просто: Ксения(1372 знак., 02.05.2011 11:32 - 11:42)
  - ...с максимальным приоритетом... ожидать окончание стирания:) - Vit(02.05.2011 21:20)
    - Да, может ждать и окончания стирания, если процессу больше нечего делать. Когда... Ксения(296 знак., 02.05.2011 22:31)
      - так вот зачем многоядерность - чтобы в RealTime делать deadlock:))) на нескольких ядрах... - Vit(02.05.2011 22:49)
  - Здорово, но не удовлетворяет экономии электроэнергии, озвученной автором. Кстати, зачем во флешь в реальном времени писать? Всё равно временные метки нужны для каждого измерения. Или это не флешь, а USB? - бомж(02.05.2011 18:35)
- Желательно "не плодить сущностей" и упростить взаимодействие процессов пусть даже ценой некоторых условий и допущений. Vladimir Ljaschko(806 знак., 01.05.2011 06:48)
  - Чтобы для нового угля всегда было место, учитывая продолжительность операции стирания, нужно иметь заметное количество свободных вагонов - Vit(01.05.2011 11:52)
- Может чего не понял, но видится так: 2 очереди транзакций - отдельно для П1 и отдельно для П2 - и кеш (в П2) для П1. Ресурсом рулит П2. Непустые очередь/кеш от П1 приоритетны. - Vit(30.04.2011 23:43)
  - дополнил пост. если бы не это дополнение - можно было бы вообще один проц ставить помощнее. кстати, как там ситуация с МК у которых несколько разнокалиберных ядер на одном кристалле? продаются уже? - Snaky(01.05.2011 02:43)
    - Lonworks Neuron chip : 3 cores, 23 years ! - Vladimir Ljaschko(01.05.2011 06:59)
      - :> я скорее это имел ввиду - Snaky(01.05.2011 10:05, ссылка)
        
        Да, это была шутка. Без конкретики проекта обсуждения принципов "семафорирования" - как знания в институте, абстрактны до бесполезности. - Vladimir Ljaschko(01.05.2011 13:25)
        
        Ответ Snaky(604 знак., 02.05.2011 03:17 - 03:34)
- Полезно познакомиться со средствами поддержки межпроцессорного обмена. Например тут (->). Читать же теорию о межпроцессорном взаимодействии, ИМХО, лишнее. В каждом конкретном случае оптимальное решение свое. Dir(59 знак., 30.04.2011 19:06 - 19:08, ссылка)
- Непонятно - вопрос аппаратного или программного решения? ASDFS(287 знак., 30.04.2011 18:27, ссылка)
  - пока что вопрос общего "архитектурного" уровня. первое приближение. окончательное воплощение может оказаться как программным, так и аппаратным, так и комбинированным, в зависимости от найденного решения. - Snaky(30.04.2011 19:07)
- Я бы подключил к флешу только П2, а П1 по spi пихал бы данные в П2, который будет писать их во флеш. - бомж(30.04.2011 17:40)
  - Наоборот. Флеш на П1, пусть пишет сразу, а в свободное время обслуживает по SPI запросы от П2. Мастер на SPI - П1. Для работы П2 программирует контроллер DMA для SPI и дергает ножку для прерывания П1. П1 забирает блок параметров у П2 выполняет vmp(34 знак., 30.04.2011 19:51)
  - убъем жесткий риалтайм П1, потому как он начнет зависеть от П2. продумываю вариант добавки П-3 как контроллера ресурса. т.е. все идет только через него, и он уже решает вопросы доступа и приоритетов. - Snaky(30.04.2011 18:11 - 18:14)
    - Если П1 только пишет, то в П2 нужно просто на SPI ДМА с буфером по больше, и никто ни от кого зависеть не будет. Вместо SPI можно использовать ну скажем Ethernet. - =AlexD=(30.04.2011 18:45)
      - добавка 1: П2 - толстый проц и т.к. он не нужен большую часть времени, то он спит для экономии энергии. П1 - рабочая лошадка - работает всегда, независимо от состояния П2. Snaky(253 знак., 30.04.2011 19:03 - 19:12)
        
        я подобное реализовывал так koyodza(826 знак., 30.04.2011 19:43)

Микроконтроллеры