Две ядра с отчасти споделен IRAM и DRAM, като в DRAM-а има секции, които в определени моменти трябва да бъдат защитени от агресор, както от външен (другото ядро), така и от вътрешен (друг процес в същото ядро).

Хмм, "агресор" не е май най-точното. Spinlock-овете са за синхронизация, от агресия пазенето е по други начини. Но предполагам просто избор на думи.

Този DRAM без кеш ли е?

Двете ядра (и съпътсващите процеси в тях) можете да помислите да ги синхронизирате с нещо като LL/SC, така хем няма да е микрокодирано (всякакви проблеми с прекъсвания/изключения), хем и размерът на кода няма да гръмне особено. Като според честотата и продължителността на "взимане" на споделените ресурси дори може да му направите една симулация. Само че след като няма кеш и кеш-кохерентен протокол между ядрата, ще трябва да си говорят някак заради тези LL/SC.

откъде тръгнахме, докъде стигнахме

И аз не схващам връзката между спинлок и MPU... Но да приемем, че е някаква "черна кутия" с която софтуера трябва да си приказва честичко и затова е нужен по-бърз достъп до нея.
Идеята тая кутия да изглежда като "скрит регистър" ми е малко мъглява. Обикновено вкарването на нов регистър означава голямо разбутване, особено ако има и конвейри... Не знам детайлите, но ми звучи плашещо и затова попитах какво точно е това животно. И дали не може да се измисли друг вариант. Примерно (ако беше спинлок) да не е регистър, а бит само, защото битовете по-лесно се синхронизират а и по-лесно се намира къде да ги набуташ. Примерно в статус регистъра на повечето архитектури обикновено има доста свободни битове и е сравнително безопасно да се барат, т.е. не разбутват времена или други инструкции... Но това май няма как да стане в случая

Извинявам се за отсъствието, но излезе непланирана командировка. Като чета и двама ви, явно не съумявам да обясня проблема или ми е грешна терминологията. Та да се върна към основите:

1. Няма кеш. Част от DRAM-а е достъпна само от съответното ядро. Друга част е достъпна от двете ядра през арбитър.
2. Арбитърът е тривиален round-robin, т.е. не предоставя възможност да се блокира единият порт докато другият изпълнява атомарни инструкции
3. Поради това spinlock-овете са имплементирани периферно, т.е. извън DRAM-a. Те разполагат с блокираш арбитър, които позволява атомарни инструкции
4. Спинлоковете се използват, когато едното ядро иска да предотврати модифицирането на данни в споделения DRAM от другото. Това по себе си е синхронизация с цел предпазване от агресор. Иначе казано преди да вляза, проверявам дали е свободно. @woody какво пропускам или ми е грешна терминологията?
5. Спинлоковете са многобитови за да може да се идентифицира процесът, който ги е заключил. Това е необходимо с цел, на базата на това кой процес е заключил спинлока, ответното ядро взима решение дали да прави polling, да смени thread-a с неконкурентен или да „приспи ядрото“. Това е един вид адаптивен scheduling.

Че сме омазали бъса, спор няма. Обаче няма как да го ускорим за този проект. Затова пипнах instruction set-а и сега двете ядра си шерват спинлоковете като отделни регистри с блокиращо арбитриране. Т.е. извън DRAM-a което ми спестява главоболието да модифицирам неговия арбитър, който пък е в най-критичния път от гледна точка на timing closure. Това което обаче взе да ме гложди е от къде на къде фирмуера минава през толкова функции докато слезе до съответния драйвер. Та и там ще се оптимира май. Но за това ги чакам да си отворят кода.

HCL, няколко въпроса:

1) Ядрата са load-store, нали? Че RISC е размито.

2) Двете ядра в един clock domain ли са?

3) Структурите от данни които се защитават със spinlock-ове са си на софтуера, и гоните просто синхронизация?

4) Текущата реализация с многото код / подпрограми прави тези "интелигентни" решения дали да върти (spinlock) или да yield-не, като последното го прави нещо RTOS-оподобно, т.е. чист софтуер?

Имам някаква дребна идея, но искам да си попълня пъзела в главата.

Може и да нямаш чак такъв проблем тогава.

Но първо да върна малко лентата. Това, за което се ползват тези spinlock-ове са mutex-и, като момците със софтуера са решили да вкарат и малко RTOS елементи. "Агресор" не звучи правилно, защото синхронизирането с mutex е доброволен процес и няма вражески елементи (за разлика примерно от ограничаване на достъп с MMU/MPU). Освен това никога не съм го виждал в този контекст, но да речем че терминологията я е хванала някаква мода напоследък.

По варианта със запазване на DRAM арбитъра неатомарен (заради критичния път) за конкретното ви приложение - аз бих сложил LL/SC инструкции. Като ресурси е на всяко ядро по един регистър за адрес (примерно 32 бита, но може и да е по-къс, колкото за DRAM-а само) и още един контролен бит.

- При LL битът се слага в 1 и адресът се запомня.
- При достъп от кое да е от двете ядра по записания адрес (нали са в един clock domain) битът се чисти в 0.
- SC успява само ако битът е 1, и тогава знаеш че mutex-а е обновен.

Има и още дреболии за конкретния ти случай, но в груби линии е това. Ако решиш да ходиш в тази посока може да продължим.

To това си е стандартно при доста архитектури, при АРМ примерно

Въпросът е дали HCL има LL/SC поддръжка и дали наистина иска да я обвържи с кърнела, което в известен смисъл е смесване на различни неща. Хубавото на условния запис е, че в рамките на едно ядро става много лесна и ефективна синхронизация между процеси с различен приоритет. Не се забраняват прекъсвания и отделно високите приоритети почти гарантирано минават от раз. Отнасят го тия с нисък приоритет, което е добре стига да не го отнесат съвсем, но то ако се стигне до там каруцата вече е обърната...
В тоя механизъм обаче кърнелът няма място. Той няма какво да помогне, атомичността си се постига прекрасно и без негова намеса. Вече евентуално след приключване на атомичните операции кърнела може да е нужен.
Иначе казано спинлок се прави само с атомични операции (чрез LL/SC или по друг начин). А вече след като е ясен резултата от спинлока може да се включи кърнела в играта.

Относно имплементацията на мониторите си струва човек да се запознае с куртексите. Те може да имат много елементарен монитор, състоящ се само от един бит и който изобщо не следи адресите. Може да е по-сложен и да след последните няколко адреса. Може и да е глабален, т.е. да следи достъпа на няколко към към shareable памет..

Добре, сега вече говорим на един език. С помоща на документа, който изпрати Миро и на следните разяснения

http://stackoverflow.com/questions/5869 ... d-of-mutex
http://stackoverflow.com/questions/2351 ... spin-locks

се коригирам съответно

1) Това което ми трябва не е нито mutex, нито spinlock, а хардуерната платформа на която фирмуера да имплементира кобинация от различни семафори (не само mutex) и spinlock.

2) Тази хардуерна платформа може да бъде имплементирана по два начина
а) с помощта на атомарни инструкции. Такива в момента не са налице, но тъй като instruction set-а е под мой контрол могат лесно да се добавят
б) с помощта на специфична периферия, която да бъде достижима от ядрото през AMBA бъса. Т.е. семафорите/спинлоковете са изнесени от DRAM-a в периферни регистри извън ядрото. Такава е актуалната ми имплементация, която макар и скъпа от гледна точка на време за достъп вършеше работа досега. Но тъй като фирмуера има намерение да използвам значително повече семафори/спинлокове в новата итерация на проекта, не е повече приложима и трябва да търся решение -> 2а.

3) Това което се крие за 2а може да бъде решено по два начина
а) атомарни инструкции за достъп до DRAM-а, където са имплементирани съответните семафори/спинлокове. Това е предложението на woody за LL/SC, както и описаното в ARM документа посочен от Миро. Елегатно и лесно скалируемо, но за съжаление няма как да го имплементирам, понеже изисква модификация на DRAM арбитъра. Тази модификация в документа на Миро е наречена Global exclusive monitor. Ограничението идва от това, че в съответния проект нямаме кешова архитектура и ядрата си споделят сравнително голямо количетво памет, което създава ограничения при floorplanning, Place&Route. Т.е. самите инструкции мога да ги добавя, но те ще са безполезни понеже няма как те да работят без Global Exclusive monitor, а той ще ми разбие timing closure-a, понеже е на критичния път от ядрото до паметта.
б) атомарни инструкции за достъп до споделен между ядрата сет от регистри. Това е решението върху което работя в момента. По принцип е същото като LL/SC инструкциите, но семафорите/спинлоковте не биват съхранени в DRAM-a, а в специален сет от регистри. Така пак имам Global exclusive monitor, но той не лежи на критичния път до паметта. Типичен пример за дуплициране на ресурси. Не особенно ефективен от разход на енергия и площ подход, но имайки в предвид ситуацията - единственият възможен. Така са възникнали и CISC архитектурите... всеки има право да си пожелае нещо

Дискусията беше много полезна, за което благодаря. Изясних си някой неща и се надявам комуникацията ми със софтуерните архитекти да се подобри в следствие.

HCL, не мога да преценя дали наистина твоето 3а) е така. По-точно дали наистина трябва промяна в DRAM RTL-а, поне на мен не ми изглежда така (но и ти си познаваш проекта, естествено). Ядрата директно могат да си предават ефективните адреси (EA), към DRAM си отиват нормални load/store заявки (в слуая на SC просто може да не отиде store заявка). Какво пропускам от моята камбанария?
Вярно е че можеш да направиш много частен случай нa LL/SС, примерно с краен брой битови полета, но това може да стане спънка с времето. Тоест, ако може да се имплементират класическите LL/SC, би било правилна инвестиция. Оттам софтуеристите ще са щастливи и ще си дялкат каквито искат синхронизационни примитиви.
Другото е че със съвсем малко още може да се направят и хибридни mutex-и.

Всъщност варианта с атомарни инструкции до споделени регистри никак не звучи зле. Верно, за да скалира неограничено трябва да емулираш с него атомарен достъп до DRAM но пък за това което успееш да синхронизираш през тези регистри няма да се налага да блокираш достъпа до паметта. Ако не е патентовано вземи го патентовай пък ако е виж да не си вкараш таралеж в гащите

Не виждам как ще стане без промяна в DRAM арбитъра. Паметта е споделена и не гарантира атомарност на инструкциите. Т.е. няма кой да блокира/заключи за да се избегне промяна по средата на цикъла. В момента ако едното ядро направи store заявка в такт едно, а другото направи store заявка в такт две ще минат и двете.

б*х мааму за това не се бях замислил... но няма страшно, политиката на фирмата е да не се проверява дали нарушаваме патенти, щото логвали какво точно търсим и ни погвали одветно и тогава се водило с умисъл и глобите били х10. В резултат на това, няма проблем да нарушаваме колкото си искаме патенти стига да е на сляпо. В най-лошия случай фирмата си плаща или вади портфолиото и се мерят пишки. Откачена история.

Това е идеята, че LL/SC са lock-free, т.е. не изискват атомарност (RMW), вътрешният флаг е този който следи и накрая SC фалира като запис ако не е било атомарно като поредица. Тоест, никаква промяна в DRAM арбитъра не трябва - навън си излизат прости load/store заявки.
Реално по времето м/у LL и SC ако някой друг се опита да направи LL по същия адрес (или с гранулярност, според имплементацията), SC фалира - не прави запис, и рапортува фал.
Смисълът на LL/SC е че ако мине записът (SC), значи гарантирано този отрязък е бил атомарен. Обратното не е вярно.
Това е и красотата пред RMW синхронизационните примитиви.

Знам че обяснявам криптично, но все още не виждам проблем. А това че двете ядра са в един clock domain е абсолютен бонус.

Ха-ха наистина малко усукано обясняваш, затова ще пробвам да кажа същото с по-прости думи...

В най-простата ситуация - 1 кур + ordered memory цялото нещо се прави с 1 тригер. Не се следят нито адреси, нито данни, нито нищо друго освен последователността на инструкциите.
Те са 3 инструкции:
1- LDR-EX (LL)
2- CLR-EX
3- STR-EX (SC)

Последната инструкция се изпълнява, ако преди нея някога във времето е имало LDR-EX и никаква друга "ЕX" инструкция по средата.

Примерно
LDREX
STREX минава
STREX - не минава
LDREX
CLREX
STREX - не минава

По средата може да има всякакви инструкции, те нямат отношение към EX-инструкциите.
Така както го описах работи при малките куртексчета (М3/4/7). Има тригер който се сетва при LDREX и се ресетва при CLREX или след STREX. Kaто STREX се изпълнява ако тригрът е сетнат и не се изпълнява ако не е.
Това нещо работи когато отвън ядрото достъпите до паметта не се разбъркват и когато естествено софтуера ползва само EX достъп. Т.е. ако една нишка ползва екслусив достъп до даден спинлок, а друга обикновен достъп... ще стане кофти.
Недостатъкът е, че ако една нишка започне екслусив достъп до един адрес, прекъснат я и в прекъсването някой ползва ексклусив до съвсем различен адрес, то след прекъсването STREX-a на прекъснатата нишка няма да мине и тя ще трябва да повтори всичко отначало. Това би могло да се подобри ако се следят адресите, но поне аз не съм виждал някой да го прави. АРМ със сигурност не го правят. То и няма много смисъл по принцип.

Сега когато са 2 или повече кура имплементацията би била малко по-сложна. Но ако няма разбъркване и кеш (д)ефекти, то не е много по-сложна. Просто трябва да се изкарат жици между ядрата и да се ресетват битовете им. Застъпването не е проблем, тъй като нищо не се прави в същия такт. Важното е да не се разрешава повече от един екслусив достъп едновременно. Кой точно достъп ще се разреши е въпрос на обмисляне на конкретното проложение. Но да кажем че два кура в един и същ такт имат LDREX. Трябва само единия да си вдигне бита, а другия (другите) - не. Пак казвам важното е да е само един, без значение кой. От тук нататък когато се стигне до STREX имаме само един кур с вдигнат бит и само неговия запис ще тръгне към паметта, останалите тъй като битовете им не са вдигнати трябва си замълчат.
Така че стига достъпите до паметта да не се разбъркват, няма никакъв проблем цялата имплементация да е само от по 1 тригер на кур. Естествено ако адресите се разпознават лесно, то може да се направят и по 2 бита на кур. Един бит за локалните адреси и един бит за шернатите. Така другите курове няма да бавят локалните операции.