[C WinApi]Wątki ,dostęp do jednej zmiennej.

0

Czy w przypadku jednej zmiennej wykorzystywanej przez
dwa wątki wymagana jest specjalna ochrona dostępu do
jej zawartości ?

Założenia :
1.Dwa wątki główny i dodatkowy
2.Oba posiadją jednakowy priorytet wykonania.
3.Wątek główny ma za zadanie zamknięcie wątku dodatkowego poprzez "wspólną zminna globalną".
4.Sytuacja jest nieco uproszczona ,wątek główny może uruchomić wątek dodatkowy po jego
zakończeniu ,przed ponownym utworzeniem wątku ma wyłączny dostęp do zmiennej tak że można
to pominąc .[czyli głównie chodzi o zamknięcie wątku dodatkowego ]

Przyklad pseudo kod:

bool zmienna = true ; // globalna np.

void wątek_dodatkowy()
{
      while(zmienna)
     {
          działa,,,
     }
}

..... 
..... 
      // wątek główny 
          zmienna = false // kończymy wątek dodatkowy
.....
...... 

Pytanie :
O ile przy ochronie kilku zmiennych których stan jest krytyczny
sytuacja jest jasna bo wiadomo że należy zablokować dostęp
innego wątku aby nie modyfikował zmiennych których wartość musi
być kontrolowana dokładnie przez jeden wątek jeśli dostęp zostanie
uzyskany do jednej zmiennej powiązanej logicznie z innymi.

W przypadku jednej zminnej zakładając że kolejność odczytania
jej wartości przez wątki nie jest krytyczna czy istnieje potrzeba
jej ochrony np. użycia specjalnych fun api używanych np.
w tzw. blokadzie wirowej aby uniknąć zakleszczenia Aplikacji ?
Czy taką zmienną należy zmieniać w sposób "atomowy" czy można
sobie dać z tym spokój,,,,

Event. czy przeniesienie kodu bez ochrony zmiennej na maszynę
wieloprocesorową nie spowoduje załamania aplikacji bez
stosowania ochrony dostępu ?

Jako że system traktuje wątki i procesy w sposób "wirtualny" mam
wątpliwości czy proba dostępu do jednej zmiennej w jednym
procesie ale przez dwa wątki wymaga specjalnego traktowania
czy można przyjąć że wszystko dzieje się szeregowo i nie nastąpi
żaden konflikt ,,,

0

jeśli do zmiennej zapisuje tylko 1 wątek, a drugi używa jej tylko do odczytu, nie ma potrzeby zabezpieczać, co innego jeśli chodzi o większe elementy...
W kodzie, który podałeś nie ma potrzeby zabezpiecznia

0

Yhy...
Tak to napisłem (minimum operacji ) że wątek dodatkowy sprawdza tylko stan zmiennej ,
zapisuje jedynie wątek główny .
(przynajmniej tak mi się wydaje [green] )
Czyli nie powinno byc konfliktu w dostępie ,,?
Przyjąć opcję jeśli nie ma konkurencji do zapisu można nie stosować ochrony ?
//Edit
No dobra nie będę upierdliwy , przyjmuję,,
dzięki crayze

0

dla pojedynczej zmiennej "konfliktów" nie będzie, co innego jeśli są tablice itp.

0

A jednak będę męczący , a tablice ? , przecież to wskaźnik ?
Co za różnica ?
//Edit
A nie już wiem chodzi o i ilość zmiennych "częśc" bez ochrony całości , może być zmodyfikowana
przez inny wątek .

dzięki ...
pozdro dzejo .

0
volatile bool zmienna = true ;
0

to wiem , ;-)

0
crayze napisał(a)

jeśli do zmiennej zapisuje tylko 1 wątek, a drugi używa jej tylko do odczytu, nie ma potrzeby zabezpieczać..

Jesli jeden odczytuje a drugi zapisuje to niestety obawiam sie ze jest potrzeba zabezpieczenia, gdyby oba odczytywaly wtedy nie byloby takiej potrzeby.
Inna sprawa, do kontroli uzywac eventow, semaforow, czegokolwiek tylko nie 'zmiennych globalnych'!!!!

0

No tak jak zwykle Pan Egonek sceptycznie podchodzi do tematu ,,,
Może się Facet trochę uśmiechnij do życia ,,,
Czyli jak to k..a rozwiązać , zabezpieczać na wszelki wypadek czy nie
, nie wiem jak to jest zrobione na niskim poziomie , gdybym wiedział nie było by problemu
, czy ktoś posiada jakąś wiedzę w tym temacie ,,,,

Eus deus kosmateus wzywam cię ,,,,

0
// bool zmienna = true ; // globalna np.

HANDLE hTerminated = CreateEvent(0,true,false,"");


void wątek_dodatkowy()
{
      // while(zmienna)
      while(WAIT_TIMEOUT == WaitForSingleObject(hTerminated,0));
     {
          działa,,,
     }
}

..... 
..... 
      // wątek główny 

      //    zmienna = false // kończymy wątek dodatkowy
      SetEvent(hTerminated);
.....
...... 

I ucz sie bo ja wiecznie zyl nie bede :P

0

Nie drażnij mnie ,sygnalizację każdy jełop może zrobić ,,,,
Ale bez ?
Jeszcze raz napiszę, Czy w przypadku jednej zmiennej istnieje potrzeba stosowania
kodu zabezpieczającego dostęp do zmiennej gdy :
1.jeden pisze
2.drugi czyta

Stan obu wątków mnie nie interesuję , ważne jest czy dostęp ogólnie
nie spowoduje zakleszczenia przy założeniu punkt 1. i 2. bez ochrony,,, .

0

TU masz wszystko w temacie.

0
dzejo napisał(a)

Jeszcze raz napiszę, Czy w przypadku jednej zmiennej istnieje potrzeba stosowania
kodu zabezpieczającego dostęp do zmiennej gdy :
1.jeden pisze
2.drugi czyta

TAK! Inaczej może być Access Violation, w momencie kiedy jeden wątek będzie czytał a drugi spróbuje pisać.

0
dzejo napisał(a)

Eus deus kosmateus wzywam cię ,,,,

...+ Egonowe 'pompuj rower dla szatana' w inszym wątku wygląda co najmniej zabawnie :>

EgonOlsen napisał(a)
dzejo napisał(a)

Jeszcze raz napiszę, Czy w przypadku jednej zmiennej istnieje potrzeba stosowania
kodu zabezpieczającego dostęp do zmiennej gdy :
1.jeden pisze
2.drugi czyta

TAK! Inaczej może być Access Violation, w momencie kiedy jeden wątek będzie czytał a drugi spróbuje pisać.

W tym wypadku? Nie może. Mamy zmienną bool, której przypisywany jest konkretny stan, zmienna ze specializerem volatile - każde użycie wiąże się z bezpośrednim odczytem lub zapisem pamięci. Z punktu widzenia IA-32 problemu nie będzie póki w grę nie wchodzą instrukcje arytmetyczne bądź logiczne jednocześnie odczytujące i zapisujące zmienną - np. dodawanie ze zmienną w pamięci jako operandem docelowym, pojedyncza instrukcja wczytuje, modyfikuje i odsyła coś, co w międzyczasie może zostać ruszone przez inny procesor\rdzeń. Problem jest taki, że nikt nie gwarantuje, że mov będzie używany do tego zawsze, że kompilator po operacje arytmetyczne bądź logicznie nie sięgnie.
Volatile oznacza tylko tyle, że zmienna może być zmodyfikowana w innym miejscu więc nie można dokonywać optymalizacji związanych z jej stanem. Akurat bool w tym wypadku jest w miarę bezpieczny, radzę jednak z takimi rzeczami uważać...
Od synchronizacji generalnie są odpowiednie funkcje WINAPI, cały system zdarzeń. Do modyfikacji współdzielonych zmiennych wymyślono zaś odpowiednie funkcje, czy to z WINAPI czy NTAPI /te swoją drogą implementują odpowiednie operacje z prefiksem lock po prostu/. Generalnie jest tak, że nie powinno się polegać na specyficznych cechach architektury i niskopoziomowych zagrywkach jeżeli ze strony systemu operacyjnego jest odpowiednie wsparcie.

0

Nie może

Dzieki za odpowiedz
ok. czyli istnieje "prawdopodobieństwo" poprawnego wykonania kodu bez ochrony zmiennej w sposób
poprawny co wynika z działania i konstrukcji tego prostego kodu , jednak nie jest znane rozwinięcie
kodu do asemblera i czy mechanizm systemu w przypadku maszyny wieloprocesorowej nie spowodouje wystąpienia błędu.
Wnioski:
Jednak interface API będzie gwarantować ochronę i nie warto podejmować próby
swobodnego odpuszczenia sobie kontroli zmiennych współdzielonych nawet w iloci sztuk 1.
dzieki
pozdro

0

przy pojedynczej, prostej, niezlozonej wartosci dajacej sie sciagnac z pamieci w jednej operacji (czyli np. prosta liczba o bitowosci <= szyny danych) i jesli strony odczytujace te wartosc nie dokonuja ZADNEGO zapisu do niej, nie powinno byc najmniejszego problemu jesli uzyje sie volatile.

to jest twarde ograniczenie, ktorego, wydaje mi sie, kompilatory nie moga i nie lamia -- tzn. jesli w kodzie zrodlowym nie ma mowy o zapisie, kod maszynowy nie bedzie go zawierac. szczerze bym sie zdziwil gdyby SAM odczyt z int'a wygenerowal kod asm ktory go odczytuje i zapisuje.. nie wykluczam, nie wchodzilem tak gleboko, ale bylbym ciezko zdziwiony.

problem z synchronizacja pojawia sie tak naprawde tylko w 2 przypadkach:

  • wtedy, gdy wartosc jest zlozona i trzeba na kilku jej fragmentach przeprowadzic spojny odczyt/zapis - 'rownoczesny' na paru fragmentach
  • wtedy, gdy jakikolwiek watek/proces chce zapisac do zasobu cos wyliczonego na podstawie wczesniej odczytanej z niego wartosci
0
quetzalcoatl napisał(a)

przy pojedynczej, prostej, niezlozonej wartosci dajacej sie sciagnac z pamieci w jednej operacji (czyli np. prosta liczba o bitowosci <= szyny danych) i jesli strony odczytujace te wartosc nie dokonuja ZADNEGO zapisu do niej, nie powinno byc najmniejszego problemu jesli uzyje sie volatile.

Pisalem wczesniej ze przy operacjach odczytu synchronizacja nie jest wymagana i szerokosc danej jak i szyny danych nie ma tu zadnego znaczenia.

quetzalcoatl napisał(a)

problem z synchronizacja pojawia sie tak naprawde tylko w 2 przypadkach:

  • wtedy, gdy wartosc jest zlozona i trzeba na kilku jej fragmentach przeprowadzic spojny odczyt/zapis - 'rownoczesny' na paru fragmentach

W tym przypadku polecalbym zablokowanie dostepu do calej struktury, poniewaz moze byc sytuacja kiedy jeden watek operuje na strukturze a drugi zada dostepu do przetworzonych danych. Moze stac sie tak ze drugi watek dostanie dane 'przetworzone w polowie'.

quetzalcoatl napisał(a)
  • wtedy, gdy jakikolwiek watek/proces chce zapisac do zasobu cos wyliczonego na podstawie wczesniej odczytanej z niego wartosci

Ta argumentacja wydaje mi sie dosc naciagana. Na moj chlopski rozum jest to po prostu sekwencyjny odczyt/zapis. Patrz wyzej.

0

obawiam sie ze nie zrozumiales tego co napisalem..

  • ustep na poczatku nie mowil o samych li tylko operacjach odczytu. kiedy WSZYSCY tylko czytaja, albo TYLKO zapisuja, sytuacja jest banalna i w ogole nie ma co jej rozpatrywac. problemy synchronizacji pojawiaja sie TYLKO gdy jednoczesnie sa i czytajacy i zapisujacy.
  • ostatnie dwa punkty to ogolne (dwa) problemy bezpiecznej pracy wspolbieznej/rownoleglej i wskazuja, ze w tym konkretnym przypadku problemu synchronizacji po prostu nie ma, gdyz zaden z nich nie wystepuje

ps. chlopski rozum sie sprawdza, ale czesto powoduje bardzo zle wykorzystanie czasu i procesorow
ps2. naciagana? jesli zapisywana wartosc nie jest 'wyliczona' i nie zalezy od przeczytanych, to mozna ten proces uogolnic do dwoch niezaleznych procesow - czytelnika i pisarza - przypadkiem serializujacych sie. a majac samych czytelnikow i pisarzy, problem redukuje sie do problemu spojnego zapisu/spojnego odczytu fragmentow wartosci, czyli problemu numer jeden. przemysl to

//egon: przynajmniej zachowaj poziom postow.. ja tez na tym nie jedną parę zębów zjadłem i akurat wiem ze jest jest bardzo wiele powodow zeby nad tym myslec. dlatego wlasnie dokladnie taka specjalizacje na studiach skonczylem. a wspomniany AccessViolation ma sie do tej dyskusji jak pięść do jeża.. nie lubie slepego i bezargumentowego uporu, EOT

0

problemy synchronizacji pojawiaja sie TYLKO gdy jednoczesnie sa i czytajacy i zapisujacy.

problemu synchronizacji po prostu nie ma

Przesunę trochę cytat , nie ma problemu bo stan zmiennej jest mało ważny,dokładnie
ustawienie lub odczyt wartości przez wątki nie jest krytyczne dla działania aplikacji,
chodzi tylko o to czy taka zmienna bez specjalnego potraktowania nie spowoduje totalnej zwiechy aplikacji .

uetzalcoatl EgonOlsen deus 0x666 dzięki ,,
z całym szacunkiem quetzalcoatl ale zakładając że wątki działają sobie swobodnie
może wystąpić próba dostępu czyta-pisze więc synchronizacja jest potrzebna ,,,
fun . lock @_0x666_ .
Coś mi to wygląda trochę sztucznie ,czy np. przeniesienie zmiennej z globalnej na lokalną np. do Klasy
,[kopiowanie przez stos] i dostęp poprzez funkcje może to rozwiązać (event wręcz przeciwnie) ,,
wepchnięcie zmiennej gdzieś dalej , kurcze nie wiem niby prosty problem ,,, który nie istnieje ?
Uciąć rozważania i załatwić z góry poprzez API , ale jakoś tak mnie swędzi że jest inne logiczne rozwiązanie.(zaznaczam że chodzi dosłownie o jedną zmienną rozmiaru bool 4 bajty na mojej
machine)
Uprzedzając krytykę:
,,, ps. tak wiem że jestem nie normalny
I ewentualne rozwinięcie tematu interesuje mnie bez inwektyw i osobistych wycieczek (mamo
a tamten to powiedział to i wcalesię nie zna w temacie i ogarnąć się nie nie potrafi ) ,,,
no zresztą wiecie o co chodzi ,,, [green] ;-) szanujcie się trochę panowie ...

0

w Twoim przypadku (tzn. w tym opisywanym na poczatku watku) jedyna zmiana jakiej mozna sie spodziewac to true->false. nie wazne z jakiego miejsca aplikacji i z ktorego watku zostanie dokonana, powinno to byc bezpieczne i nie powinno wymagac synchronizacji, CHYBA ze jest mozliwosc zresetowania tej zmiennej z powrotem na true, albo ze poza ta zmienna i petlami watkow sa jeszcze inne rzeczy ktore od niej zaleza (np. dostepnosc jakiegos wspoldzielonego polaczenia, memmapy, etc ktore sa zamykane w momencie zmienna=false)

@global->local - to to rozwiazuje problem z synchronizacja do zasobu poprzez .. zwielokrotnienie teog zasobu tak zeby kazdy watek mial swoj wlasny, do ktorego tylko on zaglada (tzn. on i ew. to-cos-co-go-zmienia). jest tylko jeden problem - w ten sposob, to-co-updateuje-te-wartosc ma do updateowania nie 1 a np. 150 do updateu.. i jesli go interesuje zeby to byla atomowa zmiana.. lapiesz;)

wracajac.. czy ten boolean jest uzywany do czegokolwiek poza zrywaniem glownych petli watkow? czy watki cos wykonuja po przerwaniu ich petli? tzn. czy to ze jeden specyficzny watek przerwie sie wczesniej/pozniej niz inny specyficzny moze czyms grozic? czy ten boolean kiedykolwiek jest cofany z powrotem do poczatkowego stanu TRUE? czy po ustawieniu bool'a na false cokolwiek zamyka jakiekolwiek zasoby z ktorych inne poza nim watki korzystaja?

jesli nie, bool jest bezpieczny i nie wymaga synchronizacji. zreszta wiekszosc w/w pytan tyczy sie i tak nie jego tylko tego co sie dzieje w okolicy i jak juz to ta okolica bylaby niebezpieczna a nie on..

0

No jak by nie było to jednorazowy odczyt, czy jednorazowy zapis bool'a jest operacją atomową i nic więcej. Do konfliktu dojdzie wtedy, gdy w jednym wątku jest odczyt + zapis na podstawie tego odczytu, a w drugim wątku jest wtedy (pomiędzy wspomnianymi operacjami) zapis. Jeśli chodzi o kontrolę wykonania wątku pobocznego przez wątek główny takim boolem to możemy być spokojni, nic się nie pochrzani. Teraz jeśli wątek główny ustawi tego boola na true sygnalizując koniec, a wątek poboczny odczyta "w tym samym" czasie jego wartość to nie ma znaczenia czy odczyta wartość pierwotną, czy już zmienioną, po prostu najwyżej wykona jedną iterację więcej.

dzejo napisał(a)

czy można przyjąć że wszystko dzieje się szeregowo i nie nastąpi żaden konflikt
Jeśli chodzi o maszynę wieloprocesorową to sprzęt (i też chyba system operacyjny) ma o to zadbać. Dokładnie nie wiem jak to działa, ale rozkminy są podobne jak przy wielodostępie do baz danych. Jest to chyba najpoważniejszy problem wieloprocesorowości, właśnie aby utrzymać spójność pamięci. Jednak człowiek to mądre zwierzę, zawsze coś wymyśli ;)

0

milo ze przelozyles teoretyczne stwierdzenia na praktyczny jezyk :) drobna tylko uwaga:

czy już zmienioną, po prostu najwyżej wykona jedną iterację więcej

jedna iteracja wiecej moze spowodowac, ze watki w nadmiarowej iteracji moga probowac dostac sie do czegos czego juz nie ma - patrz moj post wczesniej i 'pytania kontrolne'. to mozna bardoz prosto rozwiazac - zwalniac zasoby dopiero po z'join'owaniu wszystkich watkow

0

Jeśli wątek główny kontroluje zasobem, to wystarczy, że najpierw zakończy wątki poboczne lub wskaże im, aby nie korzystały z zasobu, poczeka na zakończenie lub odpowiedź od wątków i dopiero zwolni zasób. Wątek poboczny do dania odpowiedzi wystarczy, że wykorzysta drugi albo nawet ten sam bool.
Jeśli zasób może być utracony w dowolnym momencie, to i tak każdy wątek musi to kontrolować własnoręcznie, bo każdy wątek może się okazać tym pierwszym, który się odwoła do zasobu po jego utraceniu.

0

Witam

Nie jest konieczne zabezpieczanie w żaden sposób przykładu autora postu, jeżeli współdzielona jest zmienna, tablica, itd. czyli po prostu pamięć. Należy tylko pamiętąć aby zmienna współdzielona, sprawdzana w pętli była zadeklarowana jako volatile. Bez tego może sie zapętlić i nigdy nie wyjść. Większe elementy również mogą być współdzielone bez zabezpieczeń - nic się wtedy nie stanie - żaden wyjątek nie wyskoczy, zostają tylko problemy jak wspomniał jeden kolega, że przełączenie wątku może i będzie się trafiać np w trakcie wypełniania pewnego bufora, który nie będzie kompletny, stąd cała teoria o semaforach, sekcjach krytycznych, itd. generalnie synchronizacja jest potrzebna wtedy, kiedy wymagane jest aby pewne operacje na obiekcie zakończyły się w 100% zanim drugi wątek zacznie robić swoje. Zapis do pamięci oraz odczyt nie wymaga tego. Na potwierdzenie dodam że nawet wielki Borland pisząc swoją klasę TThread użył tam takiego mechanizmu do informowania o zakończeniu wątku - zmienna Terminated.

0

Chlopaki bez obrazy ale wy nie macie zielonego pojecia o tym jak dziala multithreading, po co stosuje sie zabezpieczenia dostepu do pamieci i jak projektowac stabilne aplikacje wielowatkowe.

@up: goly TThread w zasadzie dziala zle, probowalec cos na nim robic czy tylko wiesz ze cos takiego istnieje?

0

Dlaczego żle? Przecież to tylko ładnie obudowana w klasę funkcja CreateThread z WinApi a to chyba nie działa źle skoro Windowsy trwają do dziś. Używam tego, owszem, programuję zawodowo od kilku lat. Tworzyłem aplikację sieciową do monitoringu video w której równolegle działa od 5 w górę wątków opartych o TThread: zapis, odbiór, zarządzanie serverami video, serwer TCP, serwer WWW, wyświetlanie,.... Jeśli piszesz, że źle działa podaj przykład, podeślij przykładowe źródła, może coś źle robisz.

0
EgonOlsen napisał(a)

Chlopaki bez obrazy ale wy nie macie zielonego pojecia o tym jak dziala multithreading, po co stosuje sie zabezpieczenia dostepu do pamieci i jak projektowac stabilne aplikacje wielowatkowe
Dbać o stabilność trzeba w bardziej skomplikowanych sytuacjach. Przy tak prostym zadaniu aż szkoda bawić się w jakieś sekcje krytyczne czy semafory. Egon, przeczytaj założenia przyjęte przez dzejo w pierwszym poście. Chodź faktycznie jeśli sytuacja nie wiele się komplikuje można nie zauważyć, że te założenia nie są spełnione.

0

Dodam może cenną uwagę. Skoro dostęp do zwykłej zmiennej (np. int) miałby być zabezpieczany sekcją krytyczną albo semaforem to niby jak miała by być zabezpieczona zmienna sekcji krytycznej (czy też jej wskaźnik) skoro kwestia zabezpieczenia dotyczyła również wskaźnika na sekcję itd. Wyszło by, że należy zabezpieczyć sekcję krytyczną przed wielodostępem (wywołanie sekcja->Enter() lub inne w zależności od implementacji). To przeczy teorii, że należy zabezpieczać nawet dostęp do jednej zmiennej w tak banalnym przypadku jak podał autor tematu. Popieram przykład z muchą i armatą :).

0

hoho jaki gorący temat :-D
ja oczywiście także uważam, że nie ma co zabezpieczać jednej zmiennej, przynajmniej w przypadku kodu autora(tak jak napisałem jako pierwszy)...
Bo wielowątkowość technicznie nie istnieje, na jednym procesorze, a jedynie wątki się wykonują po kolei, więc jakiś jednoczesny dostęp do tej samej komórki pamięci czy coś w tym stylu nie może zajść, bo tylko 1 wątek może działać w danym czasie...

Ale jak wygląda sprawa na DualCore? Nie znam się na tym, nie posiadam dwóch procesorów w kompie i nie wiem jak to jest technicznie realizowane, ale jeśli rzeczywiście 1 wątek będzie wykonywał 1 procesor, a drugi proces inny wątek w tym samym czasie, to czy istnieje możliwość odwołania się do tego samego zasobu sprzętowego przez oba wątki, pytam z ciekawości...

0

egon: daj chociaz JEDEN przyklad spelniajacy zalozenia ktore zostaly podane i ktory wykaze nieprawidlowa prace bez recznej synchronizacji. podkreslam, musi spelniac podane zalozenia. jak na razie wykazujesz posiadaniem duzej ilosci zlych doswiadczen zapewne spowodowanych zlymi algorytmami.. a pakiet zlych doswiadczen i uprzedzen to nie jest to to samo co "posiadanie doswiadczenia w temacie multithreadingu". proponuje zebys w tym celu napisal prosty program w C++, bez komponentow borlanda, bez delphi itp. ot, czyste c++ i moze thready z boost'a zby juz Cie winapi nie meczyc. tak sie sklada ze sporo ludzi pracuje nad algorytmami nie wymagajacymi synchronizacji, poniewaz powoduje ona sztuczne spowolnienia na ktore nie mozna sobie czasem pozwolic. ba, nawet czasem zezwala sie na- i wykorzystuje sie fakt zaistnienia w algorytmie WYŚCIGU. herezeja, prawda?:)

crayze: w przypadku 2+ procesorow zachodzi fizyczna, prawdziwa rownoleglosc. kazdy z prockow bedzie mial swoja sciezke wykonywania kodu i swoja pamiec podreczna cache ktora sobie wypelni danymi z glownego RAM'u. zauwaz jednak, ze dostep do tego ostatniego musi byc juz odpowiednio separowany. w danym momencie, dany blok pamieci moze zostac zapisywany tylko przez jeden z (pod)procesorow, to jest raczej oczywiste. w przypadku komunikacji z urzadzeniami sprawa wyglada podobnie - w danej chwili czasu dostep do zapisu ma tylko jeden procesor. odczyty z kolei nie musza byc - moga chociazby byc cacheowane po drodze i udostepniane wielu procesorom na raz. mechanizmami tymi zajmuje sie hardware i tez po czesci system operacyjny. system operacyjny gwarantuje tez, ze SYSTEMOWE mutexy, sekcje krytyczne itp beda respektowane przez procesory maszyny. a jak to robi - nie musi nas to interesowac.

1 użytkowników online, w tym zalogowanych: 0, gości: 1