Пак започваме някакви глупави спорове.

За чуждицата.. може и чуждица да е, но аз предпочитам "атомична" вместо "непрекъсваема"... щото има разлики между "atomic" и "uninterruptable".

Относно read-modify-write... значи ти ако имаш такова нещо, за каква синхронизация говорим тогава?
Ти се опитваш да изкараш, че синхронизацията е проблем само за хардуеристите и всичко трябва да се решава само по хардуерен път. Това изобщо не е така. Синхронизацията си е генерален проблем, което се проявява от ниско хардуерно ниво, през софтуера до мрежови протоколи, бази данни и т.н. Теоретично проблемите са еднакви, както и решенията. Няма смисъл да се делят. Все едно да кажеш, че 2 дини + 2 дини е по-различна сметка от 2 пъпеша + пъпеша.... Две плюс две си е математически проблем

Класификацията е по други признаци... Най-същественият от които е честота, защото тя ти определя границите на синхронизация. Примерно в примера с кръговия буфер, до определена разлика в честотите на извикване на прекъсването и работата на нишката може да "синхронизраш" данните. Но при голяма разлика имаш загуба. Същото е при хардуера, където кръговия буфер е просто FIFO и ако пишеш на висока честота, четеш с ниска естествено стигаш до препълване...
Между другото синхронизацията винаги се прави еднопосочна. Когато ти трябват двете посоки, това просто са две синхронизации. Примерно няма такова животно като "двупосочно" фифо. В мрежовите комуникации пък двупосочната синхронизация е утопия, тъй като при ненадежден канал за данни тая задача няма решение. Аз мисля съм я описвал тук в класическият й вариант - една армия, разделена на две е обградила друга армия от изток и от запад. Като на север и на юг са непроходими блата, тъй че единственият начин на двете половини да си комуникират е през вражеската територия. Да речем, че командирите разполагат с безброй пратеници на които могат да предават произволни съобщения. Задачата е двата командира да си уговорят час в който да нападнат.
И те така тоя read-modify-write няма решение

Друга известна класическа задача е за "вечерящите философи"... Тук наскоро имаше задачка да се вържат 10 коня на 9 кола.... Те това е подобно - пет философа, пет чинии със спагети - по една пред всеки философ и по една вилица между всяка чиния... Проблемът е, че за да се храни един философ му трябват две вилици. Така де, това е известна задача

Ако има някакъв интерес може да отворим отделна тема за IPC (inter-process communication) и всичките й аспекти от хардуера до философията

п.с.

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

виж, ся... за съжаление умря циганката дето ме хвали, та затова ще трябва сам да се хваля... Те това със синхронизациите ми е важна част от специалността (мрежови комуникации), както и важна част от практиката

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

А бе Миро.
Прилагателното от "атом" е атомен, атомна и т.н., атомично е някакъв твой си език, не български.
Т.е. "atomic" от английски се превежда като "атомен" на български.
Или според тебе "atomic bomb" се превежда като "атомична бомба".
Атом на гръцки значи неделим, оттам идва думата във вида, в който си я чувал и ти.
За разликата между "неделим" и "непрекъсваем" в тоя контекст нямам време.

Що държиш толкова да влизаш в спорове, дето видимо (и за тебе?) не знаеш какво говориш ми е непонятно.

Що се отнася до това как ще изобретиш перпетуум мобиле - в случая неделим RMW цикъл
с обикновени load/store инструкции, като го изобретиш обади се. Многото приказки за това
кога и дали нещо трябва и кое как се прави ако не трябва да се прави не ми се четат.

Е, то атома е най-малката "неделима" частица от химична гледна точка
За мен лично "непрекъсваем" не е съвсем правилен термин - може би "цялостен". За жалост не мога да изровя лекциите ми от университета - там имаше всякакви чешити, които превеждаха всичко на български, колкото и глупаво да звучи

И аз не знам що отделям толкова време за чуждото невежество

Може би от любопитство... Чудя се защо толкова държиш всичко да е на ниско ниво, само хардуерни имплементации и само на асемблер...

То си има обяснение, ако смяташ че RMW е *единственото* решение, явно е защо ще предпочиташ да бачкаш само на асемблер. На С/С++ ще се чувстваш безпомощен, щото там няма RMW конструкция!
Колко странно... нещо което ти си мислиш, че няма алтернатива, хората са го сметнали за излишно и не са го вкарали в езика. Е та как точно да обясня на човек като теб, че С си е един пълноценен език, че има много операционни системи написани на чисто ANSI С и че те поддържат всякакви синхронизации?
Не мисля че имам някакъв шанс в подобен спор с теб, така че хайде със здраве!

Вари го печи го дървото си е дърво.

Atomic RMW е единственото решение за atomic RMW. Не можеш да го замениш с никакви еквилибристики
на какъвто и да е език. Ако не ти трябва не ти трябва - повечето от времето е така.

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

Изписал съм повече работещ код отколкото ти би могъл да изпишеш за 100 живота.
Видимо поназнайваш нещичко, но очевидно недостатъчно, та да разбереш
колко малко е то.
Защо искаш непременно да се мериш с мене не ми е ясно, очевидно не си
ми в категорята и съответно се опитвам да се държа с тебе меко - а ти току ми скачаш.
Би трябвало досега да си научил какъв е резултатът - и все такъв ще е, аз знам какво
говоря (част от това е и да не говориш, когато не знаеш - но пък се изисква акъл и
знание да разбереш кога не знаеш).

Обясни ми случай в моя пример, при произволна архитектура, при който може да се получи смесване на стари/нови данни.

Рек, нищо му няма на кода ти, ако set се прави в прекъсването и не може да бъде
прекъснато от някого, дето ще хукне да прави refreshshadow, това е очевидно.
За такова нещо и беше първото питане, така че твоето решение си му върши работа
напълно.

Моето твърдение е за по-общия случай на резервация (понеже натам май беше отишъл
разговорът когато си нямах работа да се обадя), примерно ако и set, и refreshshadow
се изпълняват в отделни таскове, все на user ниво (т.е. нямаме хардуерната защита от
прекъсването, което маскира други прекъсвания).
Тогава очевидно няма да работи (примерно прекъсваме set след като е писал 1 в mb_refreshing
но преди да напише каквото пише в m_original и пускаме целия refreshshadow, след което
set пише своето си, и готова бозата).
В тая ситуация (и двамата писачи прекъсваеми или дори отделни процесори) не е измислен
"чисто" софтуерен начин за избягване на сбозяването - което има малко общо с твоя код
в контекста, в който ти го постна, знам, че там работи.

Аз с БОГ като Димитър не искам да споря... Не съм на нужното ниво

Но за останалите простосмъртни ще обясня, че има измислени софтуерни начини (без да се използват хардуерни улеснения от сорта read-modify-write). Наричат се семафори, критични секции и т.н.
Разбира се наличието на RMW инструменти улеснява живота, защото е по-ефективно и в много случаи премахва необходимостта от използването на софтуерните примитиви за синхронизация.
Но това изобщо не означава, че две и повече нишки не могат да се синхронизират без RWM...

Това, което вероятно tqi е чел някога и си спомня е проблема с консенсуса. Атомичните операции (пардон "атомните операции" или "непрекъсваемите") се класифицират според броя на обектите които могат да синхронизират без да се стига до блокиране. В тоя смисъл RMW позволява неограничен брой обекти, нещо което наистина не може да се постигне примерно само с MOV.
Това обаче практически не променя нещата особено.
Примерно с RMW на теория два и повече обекта могат да бъзикат нещо си независимо един от друг. Да кажем че една променлива ще може да се променя от две нишки или както в случая се говори за прекъсване и основен цикъл. Без RМW същата тая променлива не може да се променя, без да се стига до блокиране на една от страните (или загуба на данни).

Защо в крайна сметка синхронизацията може да се прави с RМW или без?

Ами защото на практика няма много смисъл от WOM (write only memory виж обясненията на ДедоБоре за това животно ). Ако двата обекта не могат да бъдат синхронизирани, то файдата от RMW е никаква. В случая с прекъсването - да - няма да блокира, няма да изпуска данни, ще ъпдейтва променливата винаги. Но на практика основния цикъл няма да вижда всички промени.
И обратно без RMW прекъсването няма да може да ъпдейтва винаги, но пък когато ъпдейтва резултатът *винаги* ще е видим за цикъла.
С други думи в случая прекъсването е предващата страна, а цикъла приемащата. И независимо дали ползваш или RMW или не ползваш - ще се приемат едни и същи данни. Разликата е в предаването, което обаче никой не може да забележи.

Така че, твърдението, че без RMW не може - не е вярно! МОЖЕ !!!

Спорът е като за инструкциите за умножение и деление... Все едно да се твърди че процесор не може да прави умножение и деление ако няма такива инструкции. Естествено сметките могат да се правят и софтуерно само със събиране и изваждане. Не е като да не може... Може
Разбира се като ги имаш хардуерно е много по-удобно... ама това е друга тема

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

От друга страна малко се обърквам понеже съм си ОС програмистче, в смисъл свикнал съм
да имам семафор, мутекс и другите глезотии, който на едно C/C++ без RTOS ги нямаш.

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

хм, сигурен съм че в университета даскалите ни обясняваха как не можело да се синхронизира софтуерно, обаче реших да го проверя, и какво виждам: http://en.wikipedia.org/wiki/Mutual_exclusion#Software_solutions
имало софтуерни решения. аз навремето преди да ги чувам нещата бях правил някакво мое си софтуерно решение, което уж бачкаше, но после си мислех че щом теорията го казва, вероятно не е бачкало гаранте, просто е разчитало на някаква системна особеност. сега не съм убеден

Що да няма бе ? Ако да речем пощенските гарвани имат 10% шанс за преминаване над вражеската територия, уговарянето на часа за атака е лесно решимо. Стига да имат часовници де...

Няма значение дали шанса на гарвана е 10% или 99% щом каналът за връзка е несигурен (под 100%, а такива са всички реални канали) не може да синхронизираш на 100% двете страни. Всяко съобщение може да стигне, а може и да не стигне. Ето ти примерен диалог:

Страна А: Дай да нападнем утре по изгрев слънце
тук не знаеш дали В го е получила. Освен ако не потвърди

Страна В: Потвърждавам, да нападнем утре по изгрев...
Тук страна В не знае дали А ще получи потвърждението...

СТРАНА А: Разбрахме че сте разбрали

СТРАНА В: Разбрахме, че сте разбрали, че сме разбрали...

СТРАНА А: Разбрахме, че сте разбрали, че сме разбрали, че сте разбрали, че сме разбрали....


И така до побъркване
Няма начин с какъвто и протокол да се използва двете страни да са абсолютно сигурни. Винаги остава един малък процент несигурност...

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