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? Czyli nie wymagają
synchronizacji międzywątkowej?
Chodzi o pojedynczą operację odczytu i o pojedynczą operację zapisu:
- w systemie jednoprocesorowym, gdy procesor ma jeden rdzeń
- w systemie jednoprocesorowym, ale wielordzeniowym
- w systemie wieloprocesorowym?

I jak to jest w przypadku funkcji z rodziony Interlocked* czyli np.
InterlockedCompareExchange? Zawsze jest atomowa na każdej z tych trzech konfiguracji
sprzętowych?

ps. mowa o procesorach z rodziny x86

--
howgh
szemrany

do góry

Dnia Fri, 3 Apr 2015 10:04:52 +0200, szemrany naskrobał:

> ps. mowa o procesorach z rodziny x86

Nikt nie ma takich rozterek i/lub wiedzy na ten temat?

--
howgh
szemrany

do góry

On Monday, April 6, 2015 at 6:32:38 PM UTC+2, szemrany wrote:
> Dnia Fri, 3 Apr 2015 10:04:52 +0200, szemrany naskrobał:
>
> > ps. mowa o procesorach z rodziny x86
>
> Nikt nie ma takich rozterek i/lub wiedzy na ten temat?

Wiele lat temu, gdy przestałem się interesować asemblerem,
pozbyłem się takich takich rozterek.
Pozdrawiam

do góry

On Friday, April 3, 2015 at 10:04:54 AM UTC+2, szemrany wrote:
> 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.

> Czyli nie wymagają synchronizacji międzywątkowej?

Atomowość nie wyklucza konieczności synchronizacji, chodzi mi
o bariery pamięci (memory fence). Co z tego, że zapiszesz do
pamięci 32 czy 64 bity, jak inne procesory tego nie zobaczą?

w.

do góry

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.
W szczegolności nie musi być OK.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

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.

w.

do góry

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.

Pozdrawiam

do góry

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

do góry

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

do góry

On Thursday, April 9, 2015 at 1:20:44 PM UTC+2, M.M. wrote:
> Jakie korzyści płyną z tego w praktyce?

No takie, że jeden procesor zawsze odczyta/zapisze całe 64 bity
w całości, nie musi dbać o zapis i odczyt. Chodzi o to, że jak
zapisujesz 64-bitową liczbę to masz *gwarancję*, że zapisane zostały
wszystkie dane, a nie, że np. 1 procesor zapisał pierwsze 3 bajty,
a 2 procesor dopisał 5 pozostałych.

> 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?

Ale to jest już inny przypadek. Dodawanie, odejmowanie i operacje
bitowe też mogą być atomowe na x86, ale dla pozostałych rzeczywiście
trzeba mieć jakąś formę sekcji krytycznej.

> Na pewno z powodu pamięci cache i tak zostaną te same problemy.

Cache akurat nie ma tutaj znaczenia.

> 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.

Sekcje krytyczne, w sensie mutexy, czy semafory, jako obiekty systemowe
są wolne, a nawet bardzo wolne. Dlatego tam gdzie liczy się wydajność
pojawiają się algorytmy lockfree, czyli nie ma jako takiej blokady na
sekwencję instrukcji, ale np. próbuje się do skutku wykonać jakąś
operację, powiedzmy dopisania do kolejki. I tu już można to robić
wydajnie właśnie operacjami atomowymi (głównie compare & exchange)
no i trzeba pamiętać o barierach pamięci (memory fence).

w.

do góry