eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingAtomowość operacji vs wieloprocesorowośćRe: Atomowość operacji vs wieloprocesorowość
  • Data: 2015-04-09 15:01:22
    Temat: Re: Atomowość operacji vs wieloprocesorowość
    Od: Adam Klobukowski <a...@g...com> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    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.

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

    AdamK

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: