Użytkownik "Queequeg" napisał w wiadomości grup
dyskusyjnych:c6cda8fa-82c3-48a0-a47d-aba030a5831b@tr
ust.no1...
J.F. <j...@p...onet.pl> wrote:
>> Cos w tym jest, ale z drugiej strony - skoro uzywamy volatile, to
>> wiadomo ze zmienna moze sie zmieniac w przerwaniach czy w inny
>> niekontrolowany sposob, i co - kompilator to olewa ?

>Ale co kompilator może zrobić, jak sam procesor nie obsługuje
>atomicznego
>dostępu do tej zmiennej (bo np. jest 8-bitowy, a zmienna 16-bitowa)?

To samo, co programista ma zrobic :-)

>Zresztą nawet w przypadku zmiennych o rozmiarze równym szerokości
>magistrali danych nie ma gwarancji chociażby w przypadku operacji
>read-modify-write. Przykład:

>#v+ test.c
>volatile int i;
>void fn(void) { ++i; }
>#v-

>#v+ test.s
>ldr r3, [r2] ; odczyt zmiennej z pamięci do rejestru r3
>add r3, r3, #1 ; dodanie do rejestru r3 liczby 1
>str r3, [r2] ; zapis rejestru r3 z powrotem do pamięci
>#v-
>Zmienna może się zmienić między każdą z tych instrukcji.

Cos w tym jest.

>> No coz, przejsc na ARM i zapomniec o problemie ...

>Czemu? Co ma do tego ARM? Chodzi o szerokość magistrali danych? To
>rozwiązuje tylko jeden problem,

Tak, problemu z int nie bedzie :-)

>ale inne (chociażby ten pierwszy przykład wyżej) pozostają.

Ciezkie jest zycie programisty.

I co sie dziwic, ze MS w C# zrobil stringi niemodyfikowalne ...

J.