On Thursday, April 9, 2015 at 3:01:23 PM UTC+2, Adam Klobukowski wrote:
> W dniu czwartek, 9 kwietnia 2015 13:20:44 UTC+2 użytkownik M.M. napisał:
> > On Wednesday, April 8, 2015 at 11:21:16 PM UTC+2, Wojciech Muła wrote:
> > > On Tuesday, April 7, 2015 at 5:28:46 PM UTC+2, Maciej Sobczak wrote:
> > > > W dniu wtorek, 7 kwietnia 2015 10:18:29 UTC+2 użytkownik Wojciech Muła
napisał:
> > > >
> > > > > > Czy operacje typu zapis/odczyt na pojedynczej komórce pamięci
> > > > > > (32-bitowej na platformie 32-bitowej, 64-bitowej wna platformie
> > > > > > 64-bitowej) są atomowe?
> > > > >
> > > > > Są atomowe.
> > > >
> > > > Dorzućmy może wymaganie na wyrównanie adresu do rozmiaru tej komórki,
> > > > żeby nie było problemu z dostępem do danych przekraczających granicę
> > > > słowa. Intuicja (na tzw. popularnych platformach) podpowiada, że wtedy
> > > > będzie OK, ale techniczna prawda będzie tylko w dokumentacji procka.
> > >
> > > Tom 3A "8.1.1 Guaranteed Atomic Operations":
> > >
> > > The Intel486 processor (and newer processors since) guarantees
> > > that the following basic memory operations will
> > > always be carried out atomically:
> > > * Reading or writing a byte
> > > * Reading or writing a word aligned on a 16-bit boundary
> > > * Reading or writing a doubleword aligned on a 32-bit boundary
> > >
> > > The Pentium processor (and newer processors since) guaran
> > > tees that the following additional memory operations
> > > will always be carried out atomically:
> > > * Reading or writing a quadword aligned on a 64-bit boundary
> > > * 16-bit accesses to uncached memory locations that fit within
> > > a 32-bit data bus
> > >
> > > The P6 family processors (and newer processors since)
> > > guarantee that the following additional memory operation
> > > will always be carried out atomically:
> > > * Unaligned 16-, 32-, and 64-bit accesses to cached memory
> > > that fit within a cache line
> > >
> > >
> > > Teraz chyba nie ma wątpliwości.
> > >
> >
> > Jakie korzyści płyną z tego w praktyce?
> >
> > Jak mam przypisanie:
> > zmienna_lokalna = zmienna_globalna;
> > Zmienna globalna mogła zostać zmodyfikowana przez inny wątek/proces.
> >
> > Jeśli dostępu do zmienna_globalna nie obejmę sekcją krytyczną, to
> > wiem że dane w zmiennej globalnej i tak będą spójne. Ale co w sytuacji, gdy
> > wątek modyfikujący robi:
> > zmienna_globalna += cos;
> > albo
> > zmienna_globalna *= cos;
> > zmienna_globalna %= cos;
> >
> > Czy dane nadal będą spójne?
> >
> > Na pewno z powodu pamięci cache i tak zostaną te same problemy. Wątek
> > odczytujący może otrzymać zmienna_globalna z opóźnieniem. Czyli wątek
> > zapisujący i tak musi zrobić powolną operację zrzutu zmodyfikowanych
> > danych. Nie lepiej od razu użyć sekcji krytycznej i mieć prostszy kod w
> > analizie, nie wspominając o możliwości kompilacji na inne procesory, albo o
> > uruchamianiu na klastrze.
>
> Nie wiesz też co z twojego kodu zrobi kompilator, może to zoptymalizować do 1
odczytu i 1 zapisu.

Zgadza się, dlatego (też) taki jestem ciekawy do czego jest to w
praktyce potrzebne.

>
> Tak więc sekcja krytyczna albo mutex jest niezbędna.



Pozdrawiam