Отговори на тема  [ 33 мнения ]  Отиди на страница Предишна  1, 2, 3
ARM мутекси, st32F4 __DMB() - как се ползва 
Автор Съобщение
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 8973
Местоположение: Добрич
Мнение Re: ARM мутекси, st32F4 __DMB() - как се ползва
Zdrav написа:
Просто трябва нормалния Store да сваля резервацията мисля. Същото което прави и условния Store. Защо трябва да се сравняват адреси и да се правят синхронизации.

По-горе се опитах да го обясня...
За да сваляш резервация, трябва да следиш всички нормални store-ве от всички ядра. При едно ядро и ако е просто е възможно. Но при малко по-сложна система увисваш като прани гащи, защото писанията са по-скоро стриймове, демек ядрата си изпълняват store инструкции, но не чакат да се запише всичко. Така "писанията" се нареждат в опашки, кешове и на практика във всеки един момент може да имаш десетки висящи писания пръснати на 100 места.
Кое точно писане от тия 100 искаш да ти развали резервацията? Да не говорим, че освен ако софтуерът не търкаля някакъв "read only" алгоритъм е почти изключено да няма висящи писания някъде. Демек ако всяко писане чисти резервации, може резервациите ти никога да не са успешни.
Следователно никак не е добра идея всяко писане да се следи. Следва варианта да следиш само определени писания - в същия регион или на същия адрес. Само че за да го направиш това, трябва да сравняваш адреси/региони. Но за да може да сравняваш трябва да си в един клок регион. Сравнението на данни от различни клок региони не е тривиално нещо. На практика едно от най-трудните неща за всеки, който проектира хардуер. Говоря, че едно единствено сравнение е проблем, а десетки или стотици сравнения си граничи с безумие. Но е достатъчно само едно сравнение да направиш, за да разбереш проблема. Не е невъзможно, даже и аз съм правил подобни глупости, но цената на това е безсмислено висока.


Цитат:
По моята лаишка логика CAS има резултата от сравнението и е осакатяване ако този резултат не е достъпен за ядрото. Последващо четене и сравнение вече не е част от atomic операция.
Така или иначе DSMC прави read-modify-write, дали резултата ще отиде до ядрото какво ще промени това във философията?


Убягва ти архитектурата...
Значи ядрото ти е конвейр с да кажем 5-10 стъпки. Навън също имаш нещо като конвейр, само дето е за данни. За разлика от конвейра вътре в чиповете, навън може ти се налага да ходиш по писти и по други причини не винаги може да си позволиш толкова висок клок, колкото вътре. Отделно тъй като може да имаш шини и да се налага арбитрация, или пък имаш контролер на паметта, който опреснява и т.н. почти задължително имаш кеш. А даже и да имаш пряк път за некеширани операция той пак не е толкова "пряк". Нужни са доста клокове за могат данните от ядрото да стигнат до паметта или обратно.
По степен на сложност най-лесен е пътя към паметта. С кеш/буфер спасяваш положението. Следващия по сложност е пътя от паметта, демек четения. Тук се правят много трикове - като почнеш от спекулативни четения, така че данните да са "под ръка", кешовете също помагат донякъде. Отделно и вътрешния конвейр е така проектиран, че адресите да са ясни колкото се може по-рано, пък данните от четенето да са необходими колкото се може по-късно. Общо взето рядко едно ядро успява (някои никога) да чете без да блокира конвейр.
Следващият вариант е read-modify-write. Това е вече отживелица, защото дори и тези архитектури които успяват да прекарат и четения и писания за един клок го правят като прекарват само едната операция.
Демек могат средно да имат едно четене или един запис на клок, но адресите трябва да са различни. Просто това е конвейр и когато четенето "излиза" следващата инструкция която ползва данните трябва тепърва да "влезе". Затова четене-смятане-писане ти е над 5-10 клока или там колкото ти е конвейра, без да броим външните забавяния.
Ситуацията особено се усложнява когато ядрото не е само и директно вързано към централна памет. Както е в примера с STM32H7 където имаш 7 различни памети, имаш още 10-20 мастера, имаш различни шини на различни честоти. В такива ситуации ако тръгнеш да ползва read-modify-write просто убиваш ядрото.
А пък вариантът който ти искаш е write-modify-read e още по-тежък, защото писането трябва да стигне до контролера и то по нормалния ред и не може да се кешира. За четенето пък не може да имаш спекулативен елемент. Евентуално може да се направи по-пряк път, но така или иначе това не решава проблема.

С други думи чистия екслузив е единственото решение, което е просто и универсално. Всяко друго решение или ще е на солена цена или ще е решение само в конкретна и контролирана ситуация.


Пон Юли 12, 2021 12:10 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Сря Апр 27, 2005 11:48 am
Мнения: 2576
Мнение Re: ARM мутекси, st32F4 __DMB() - как се ползва
абе тоя измислен мулти-кор няма ли си SDK или са го оставили всеки да се оправя кой как може...

_________________
main[-1u]={1};
http://www.wizio.eu/


Пон Юли 12, 2021 2:05 pm
Профил ICQ
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Сря Яну 26, 2005 1:01 pm
Мнения: 1928
Местоположение: Варна
Мнение Re: ARM мутекси, st32F4 __DMB() - как се ползва
miro_atc написа:
Zdrav написа:
Просто трябва нормалния Store да сваля резервацията мисля. Същото което прави и условния Store. Защо трябва да се сравняват адреси и да се правят синхронизации.

По-горе се опитах да го обясня...

Е и аз мислех, че по-горе съм го написал, но явно нещо се омешаха контекстите. Това дето си цитирал беше казано в контекста на едно ядро.

miro_atc написа:
Цитат:
По моята лаишка логика CAS има резултата от сравнението и е осакатяване ако този резултат не е достъпен за ядрото. Последващо четене и сравнение вече не е част от atomic операция.
Така или иначе DSMC прави read-modify-write, дали резултата ще отиде до ядрото какво ще промени това във философията?

Убягва ти архитектурата...

Не мисля.
В това MCU наред с LL/SC има и Read-Modify-Write, които заключват бъса, колкото и голяма отживелица да е това. Още повече конкуренцията им от Infineon имат същата отживелица с малката разлика, че отживелицата на Infineon не страда от ABA problem
В този ред на мисли, не мисля че е продуктивно да предъвкваме обясненията, колко сложно било да се направи. Или каква отживелица било да се заключва бъса с read-modify-write.

_________________
Най-опасният враг на истината и свободата е мнозинството.


Пон Юли 12, 2021 4:09 pm
Профил
Покажи мненията от миналия:  Сортирай по  
Отговори на тема   [ 33 мнения ]  Отиди на страница Предишна  1, 2, 3

Кой е на линия

Потребители разглеждащи този форум: 0 регистрирани и 8 госта


Вие не можете да пускате нови теми
Вие не можете да отговаряте на теми
Вие не можете да променяте собственото си мнение
Вие не можете да изтривате собствените си мнения
Вие не можете да прикачвате файл

Търсене:
Иди на:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.
Хостинг и Домейни