|
nedoPC.orgElectronics hobbyists community established in 2002 |
|
nedoPC-580 (SMP на 5 процессорах КР580ВМ80А)
Author |
Message |
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22802 Location: Silicon Valley
|
хм, а какая запись будет?...
угу
тогда обращение к хардверному семафору, защищающему доступ к софтверным мьютексам (а также 7 другим критическим абстракциям - по 1 биту на каждую), будет выглядеть так:
P.S. Биты в порту 7 можно поделить между следующими "семафорами":
P.P.S. Семафоры внутренние, т.е. не входят в публично доступный API - это лишь соглашение о взаимодействии супервайзера (процессор номер ноль) и операционки на рабочих процессорах...
|
31 Aug 2012 07:02 |
|
|
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
|
На фирменных диаграммах тут указывают минимальный интервал между спадом F1и фронтом F2. В этом же случае:
Этот минимальный интервал примерно и получается.
_________________ iLavr
|
31 Aug 2012 09:46 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22802 Location: Silicon Valley
|
| | | | Lavr wrote: На фирменных диаграммах тут указывают минимальный интервал между спадом F1и фронтом F2. В этом же случае: Этот минимальный интервал примерно и получается. | | | | |
Угу - я уже потом прочитал в таблице времён, что между спадом Ф1 и фронтом Ф2 минимум 0 нс может быть, т.е. всё ок
|
31 Aug 2012 09:48 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22802 Location: Silicon Valley
|
|
01 Sep 2012 14:25 |
|
|
He3HauKo
Senior
Joined: 09 Aug 2012 11:20 Posts: 176 Location: 95.135.174.189
|
Ага в точку, особенно тот момент, чем больше процессоров тем медленнее доступ.....
_________________Хочу стать всезнайкой
|
01 Sep 2012 15:24 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22802 Location: Silicon Valley
|
т.к. Lavr ещё больше года назад высказал мысль, что надо меньше слов и больше кода:
Вот вам больше кода
Более детальный код работы с мьютексами на рабочих процах:
|
01 Sep 2012 15:37 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22802 Location: Silicon Valley
|
Доступ к чему?
На самом деле масштабируемость системы сильно зависит от масштабируемых задач. В обычном SMP (на интеловских процах) важна влезаемость задачи целиком вместе с данными в кеш процессора - тогда процессы мешать друг-другу не будут. А в нашем же случае процессы вообще могут друг от друга не зависеть, т.к. доступ к памяти абсолютно прозрачный и параллельный. Но вот когда добавляется синхронизация - тут пока похоже без торможения на некоторое непродолжительное время никак не обойтись...
|
01 Sep 2012 17:23 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22802 Location: Silicon Valley
|
По семафорам - доступ в список всех возможных процессов (там где указывается наличие и местоположение процесса плюс приоритет - до 256 байт) и список активных процессов (4 байта или чуть больше, если нужно будет хранить дополнительную информацию кроме номера процесса, запущенного на каждом процессоре) наверное стоит покрыть одним семафором (bit 0) - всё равно к ним в одно и тоже время доступ нужен в большинстве случаев. Далее нужно придумать как мы будем обозначать процессы, висящие в ожидании мьютекса (или сообщения из очереди) - ведь им ненадо передавать управления пока мьютекс не освободиться.
Итак, таблица всех процессов в системе - скажем пусть будет 255 max:
В первом байте указано максимальное кол-во возможных процессов в системе - пусть будет 255. Далее идёт кол-во байт, равное кол-ву возможных процессов. Ноль внутри байта процесса будет означать, что процесса с таким номером несуществует. Если значение байта неравно нулю, то такой процесс есть - младщие 5 бит будут означать номер страницы памяти, в которой физически расположен процесс (возможные значения от 1 до 31), а старшие 3 бита будут означать приоритет процесса (возможные значения от 0 до 7). Если приоритет процесса 0, то это может значить, что он специально остановлен либо что он висит на мьютексе или ожидает прихода евента из очереди - за более подробной информацией по этому поводу надо будет идти в другую таблицу (я её пока не придумал). Таблица активных процессов:
В первом байте указывается количество рабочих процессоров, а далее идёт таблица из такого количество 16-битных слов - в младшем байте каждого слова (первом байте) содержится идентификатор процесса, который запущен на соответствующем процессоре (возможные значения от 1 до 255, а 0 означает что ничего не запущено), а в старшем (втором байте) - кол-во прерываний (10 Гц), оставшихся до переключения контекста на соответствующем процессоре.
Last edited by Shaos on 02 Sep 2012 12:58, edited 2 times in total.
|
01 Sep 2012 23:20 |
|
|
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
|
Ну когда есть код - меня сразу тянет его компильнуть, залить в систему, поюзать и подебужить... А модели железа у нас никакой нету... А кто-то у нас тут говаривал - " нефиг читать русскоязычную Педивикию на ночь" ? Точнее будет: phantasmal nedoPC-580/SMP...
_________________ iLavr
Last edited by Lavr on 01 Sep 2012 23:27, edited 1 time in total.
|
01 Sep 2012 23:20 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22802 Location: Silicon Valley
|
Теперь про переключение контекстов. На каждом проце у нас будет свой планировщик, каждый из которых будет переключать задачи по прерыванию 10 Гц (если они не запрещены). Каждый проц знает свой номер (скажем IN 4 будет давать общее кол-во рабочих процов в системе, а IN 5 - номер текущего проца, где была вызвана эта команда) - в обработчике прерываний смотрится количество оставшихся тактов процесса, если не 0, то уменьшаемых на 1 с+ отпусканием прерывания, а если 0 (процесс исчерпал свой лимит), то происходит переключение контекста - планировщик, чтобы найти следующий процесс который надо запустить, просто идёт по таблице всех возможных процессов (D_PROC) начиная от текущего, ища следующий ненулевой описатель, соответствующий которому проц не входит в список активных процессоров (D_ACTP) - в этом случае происходит переключение контекста на этот процесс и отпускание прерывания.
После некоторых раздумий решил, что возможность явного вызова планировщика (без прерывания) также нужна - например когда процесс решил, что ему надо повиснуть на мьютексе, он может немедленно отдать управление следущей задаче, а для этого надо запустить планировщик...
|
01 Sep 2012 23:48 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22802 Location: Silicon Valley
|
| | | | Shaos wrote: Теперь про переключение контекстов. На каждом проце у нас будет свой планировщик, каждый из которых будет переключать задачи по прерыванию 10 Гц (если они не запрещены). Каждый проц знает свой номер (скажем IN 4 будет давать общее кол-во рабочих процов в системе, а IN 5 - номер текущего проца, где была вызвана эта команда) - в обработчике прерываний смотрится количество оставшихся тактов процесса, если не 0, то уменьшаемых на 1 с+ отпусканием прерывания, а если 0 (процесс исчерпал свой лимит), то происходит переключение контекста - планировщик, чтобы найти следующий процесс который надо запустить, просто идёт по таблице всех возможных процессов (D_PROC) начиная от текущего, ища следующий ненулевой описатель, соответствующий которому проц не входит в список активных процессоров (D_ACTP) - в этом случае происходит переключение контекста на этот процесс и отпускание прерывания. | | | | |
Хотя наверное с нашим небольшим количеством процов можно оба значения утолкать в один порт, т.е. IN 4 может возвращать в младших 4 битах порядковый номер процессора (1,2,3,4), а в старших - общее их количество в системе (4). В будущем совершенно прозрачно с точки зрения софта можно воткнуть 8 или даже больше процессоров (до 15).
Другой вопрос как проще это сделать - сначала я думал про программный вызов, а сейчас вот подумал о возможности внеочередного вызова прерывания планировщика через запись некоего бита в какой-то порт, хотя с другой стороны непосредственный вызов RST 7 сделает тоже самое, что и аппаратное прерывание...
Такой код не будет ставить 0 в качестве приоритета ожидающего процесса, как я предполагал в начале, т.е. процесс всё равно будет вызываться планировщиком (разве что можно сделать какой-то другой вызов вместо RST 7, чтобы не отрабатывался приоритет для ожидающего треда), но при вызове он только будет проверять мьютекс на свободность (такая проверка не требует хардверного семафора) и если он свободен, то пробовать его опять захватить прикрывшись семафором, а если занят, то управление опять будет передано другому треду через непосредственный вызов планировщика.
P.S. В этом коде я вижу несколько потенциальных проблем: первая - это то что ожидающий процесс всё равно будет получать управление чтобы проверить, что он всё ещё должен ждать, тратя на это циклы ЦПУ; вторая - возможны гонки из-за того, что освободившийся мьютекс будет захвачен первым попавшимся процессом, а не тем, кто стал ждать его раньше (очереди нету), т.е. я вполне могу представить себе ситуацию, когда один из ожидающих тредов не сможет получить мьютекс никогда, если его достаточно активно будут юзать другие более удачливые треды - чтобы это дело улучшить можно добавить некую случайность в длительности ожидания; третья - надо поставить проверку на то, что мьютекс уже занят тем же самым процессом, что по хорошему должно приводить к фатальной ошибке и остановке системы (сейчас это приведёт к дед-локу). А вообще наверное для первого приближения код вполне приемлимый - можно будет погонять на эмуле ставя разное количество процессоров и наблюдая за масштабируемостью разных задач...
|
02 Sep 2012 11:17 |
|
|
BarsMonster
Senior
Joined: 21 Jul 2012 15:56 Posts: 126 Location: Zürich, Switzerland
|
На правах натюрморта:
|
02 Oct 2012 15:23 |
|
|
He3HauKo
Senior
Joined: 09 Aug 2012 11:20 Posts: 176 Location: 95.135.174.189
|
Перечитал всю ветку, но так и не понял, как они одновременно лазают в память????
_________________Хочу стать всезнайкой
|
09 Dec 2012 03:38 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22802 Location: Silicon Valley
|
А так - современная память быстрее старых микропроцессоров в несколько раз - соответственно циклы обращения к ней можно сделать сильно короче и разнести по фазам. Процы параллельно обращаются к памяти своими длинными циклами, а некая логика внутри этих длинных циклов дёргает одну и туже память в разные моменты времени - соответственно процы друг-другу не мешают. Вобщем как-то так...
|
09 Dec 2012 04:10 |
|
|
He3HauKo
Senior
Joined: 09 Aug 2012 11:20 Posts: 176 Location: 95.135.174.189
|
Так и думал!
Я когда хотел объединить два Z80, подсчитал количество тактов при разных ситуациях, а также сами ситуации, понял что случаются когда два одновременно лезут в память. А тут 5
_________________Хочу стать всезнайкой
|
09 Dec 2012 04:19 |
|
|
Who is online |
Users browsing this forum: No registered users and 7 guests |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
|
|