Чета това
https://developer.arm.com/documentation/dui0489/c/CIHGHHIE
пише, че __DMB() се отнася за предходната инструкция (вероятно машинен код)
и, защото не му разбирам, не ми е ясно как е правилното ползване на C.
Преди проверката на цикъла или след нея трябва да бъде?
Въобще, ще съм благодарен за всяка насока (и критика ) във връзка с организиране на нещо като mutex.

или

За истински мютекс не ти трябва бариера. Само ексклузив достъп е достатъчен.

Бариерка може и да ти трябва ако смесваш нормален достъп и ексклузив, но не съм сигурен. Никога не съм правил подобна глупост и честно казано не знам. Всъщност донякъде може и да съм правил, някои от регистрите на STM са кофти. Примерно при старите GPIO няма как да клатиш или конфигурираш отделен пин по надежден начин. Но пък регистрите не са кеширани така че дори и да съм смесвал достъпи при тях пак няма нужда от бариери.

Благодаря! От къде да прочета повече по темата? или някакъв промер?

Ако държиш да се образоваш трябва да изчетеш документацията на АРМ. Която е доста пръсната, отделно имаш референс манюал отделно още 100 pdf-a.
Почваш да ги сваляш в една папка и така... После трябва и чаршафите на ST-то да прегледаш, да се съобразиш коя памет в конкретния чеп каква е, дали е с кеш, дали е без.

Но за софтуера обикновено първо се преглеждат няколко готови реализации и съответно ти си вземаш мютекси или каквото ти трябва наготово. Само ако забележиш нещо прекалено съмнително или нещо те притеснява търсиш документации... Звучи непрофесионално, но и аз за много неща така процедирам напоследък

memory barrier, mbar или msync се слага непосредствено преди освобождаването на мутекса. Когато мутекса се ползва от повече от едно ядро.
Което ако се съди по това "st32F4" в загланието на темата явно не е твоят случай.
Но пък ако разглеждаш имплементация на мутекс и там има mbar, провери дали не става въпрос за многоядрен процесор.
Но може пък някой също така да се е чесал по врата като е копирал код за мутекс от някъде и накрая да е оставил "една бариерка" ... Ей така против уроки

уверих се, че е така , благодаря !

"... Ей така против уроки ..."

например Microsoft на М0+
https://github.com/microsoft/uf2-samdx1 ... ain.c#L184

Ето едно четиво точно по темата:
https://developer.arm.com/documentation/dai0321/latest/

"4.19 Semaphores and Mutual Exclusives (Mutex) - unicore and multicore"
на стр. 49

Примерният код много прилича на постнaтият в началото на темата, но след това следват уточненията на следващата страница:


Не съм детайлно запознат с Cortex-M имплементациите, но би трябвало двойката ексклузивни load/store да минава покрай кеша.
Но от ARM и те са се застраховали и са използвали израза: "this is not guaranteed if...".
За повечето писачи на код това автоматично означава: "тури една бариерка да ти е мирна главата".

В същия pdf е писано и за това дали е нужна бариера между инициализацията и разрешаването на прекъсванията.
И пак тълкуването от писач на код в повечето случаи ще е в полза на "връзванетоначервенконец".
Но там това е бял кахър защото през бариерата се минава еднократно при стартиране. Докато мутекса може да се ползва често и всяко излишно изчакване да се мултиплицира.

При М3 реализацията на LD/STEX е супер елементарна. Следи се само последователността, т.е. няма нищо общо нито с паметта, нито с кеша ако има такъв. Дори адресите да са различни (т.е. различни мютекси) пак гърми. Аз затова гледам да не ползвам ексклузив много-много в прекъсвания, защото отдолу се накъсва да цикли. Не знам при М4 дали са подобрили нещо, но дълбоко се съмнявам.
Така че при еднокуров чеп гарантирано няма смисъл от никакви червени конци. Въпросът е при многокуровите и като гледам че там слагат хардуерни мютекси си мисля, че там и конците не помагат. Не съм проверявал, но явно ексклузива е само в рамките на ядрото. Или поне не го свързват с другите ядра. И предвид това че екслузива не се интересува от памети и кешове, определено не върши никаква работа за мютекс между ядра. Някой ден ще го проверя, но почти съм сигурен че е така...

Е, тя бариерата преди освобождаване на мутекса е за да се гарантира приключване на промените по ресурса който е защитен от мутекса. Не заради имплементацията на самият мутекс.

Днес проверих. Но не на Cortex, а на едно PPC. Но и при тях документацията е така написана, че при оптимистично четене на първи пас, оставаш с впечатлението, че двойката екслузив Load/Store върши работа и при повече от едно ядро.
Това вероятно е така, но само ако има имплементиран съответния external интерфейс, защото иначе reservation(така викат на екслузив двойката във PPC Вселената) си остава само за ядрото.
На всичко отгоре в многоядрено МЦУ, не всички ядра имат т.нар. reservation. В моя случай от три ядра едното няма, другите две имат, но нямат имплементиран съответния външен интерфейс за да може едното ядро да "разваля" reservation на другото ядро.
И там имплементацията е съвсем проста. Екслузив Load сетва бит в специален регистър на ядрото и този бит се сваля от всяка операция запис към цялото адресно пространство от съответното ядро. Екслузив Store проверява същият този бит и вдига флаг. И толкоз.

Така че Миро това което казваш го виждам макар и не за Cortex. Но стила на мъгляво писане на уж конкретна техническа документация е съшият. Вероятно и имплементацията при Cortex е подобна. - екслузив може да върши работа и при многоядрено МЦУ, но в повечето случаи нещо липсва.

Мутексите в многоядрения ОС, който ползваме на това PPC, са имплементирани с друг вид atomic операция - decorated storage
Погледнах имплементацията на мутекса в един от предните проекти, където ОС-а не са успели да го "направят" многоядрен - мутекса е с екслузив Load/Store. Съответно от две ядра едното стоеше в shutdown и другото беше натоварено като кираджийско магаре.

Виж не бях се замислял за тая подробност щото не ми се е налагало

Загриза ме да задълбая едно-две нива по-надълбоко. И се оказа, че дори ако между ексклузив двойката Load/Store вмъкна нормален Store към същия адрес, виждам, че стойноста се променя, но ексклузив Store не се усеща и замазва отгоре стойноста която трябва да запише уж условно.
Т.е. в тази имплементация, която имаме при нас, освен че ексклузив двойката Load/Store не е multi-core ами осигурява atomic read-modify-write, само ако всички, които правят промени по дадения адрес от паметта, използват също ексклузив Load/Store.
В същото време "Programmer’s reference manual" е категоричен. В частта къде се описва как работи PPC варианта на ексклузив Store (store word conditional indexed - stwcx) дори не уточняват че е имплементационно зависим, а в прав текст говорят че други процесори или механизми(DMA?) могат да "развалят" reservation направен от ексклузив Load(load word and reserve indexed - lwarx).

В общия случай говорим за load-linked/store-conditional (LL/SC). А в конкретния за т.нар. weak LL/SC.
А моята мечта е формулирана като: transactional memory. И по-точно хардуерна имплементация на transactional memory.
Но изглежда, че това е препъни камък за големите батковци в хардуерния дизайн. Какво остава за ширпотребата, която ползваме.

Кое power ядро това? То си е неработене както го описваш. Имам под ръка G2LE ядро, не съм хващал подобно нещо и с предишното, но не съм и търсил.
Помня, че E6 ядрото им имаше някакво безумие, lwarx/stwcx според errata-та можеше да накара машината да увисне ако кодът забрави stwcx...
(За непознаващите power, тия инструкции са *user level*..... на времето това ме отказа от това ядро, инак му се облизвах преди 10-15 години).

Ядрото е: e200z4
В ето това MCU: SPC58NN84

Изтествах моето, работи според очакванията. По спомен писането няма особено значение къде е за да развали lwarx резервацията,
тествах го на съседния .l адрес. Очевидно адресът трябва да е в системната памет, ако минава през разни PCI-щини и подобни
няма как да работи. Обаче в твоето MCU трябва да си работи в RAM-а, не ми е ясно какво са си мислели, че правят.
Не съм има контакт с това баш ядро ама то това както спомена по-горе е общовалидно, чак ме накара да тествам това
с което живея в момента...