Niezależnie od tego, czy używana jest pamięć współdzielona, ​​czy przetwarzanie rozproszone,

Question

Go ma hasło "Nie komunikuj się poprzez dzielenie się pamięcią, zamiast tego dziel się pamięcią, komunikując się". Zastanawiałem się, czy Go używa pamięci współdzielonej lub metody obliczeń rozproszonych. Na przykład dla MPI jest wyraźnie rozpowszechniany, OpenMP jest wyraźnie wspólną pamięcią; ale nie byłem pewien, czy Go, co jest wyjątkowe.

Widziałem wiele postów, takich jak Shared memory vs. Go channel communication, skuteczny dokument Go itp., Ale nie mogłem wyjaśnić. Z góry dziękuję.

Answer 1

Go nie zapobiega dzieleniu się pamięcią między goroutinami/wątkami. Przez komunikację rozumiemy, że wysyłamy porcję danych lub wskaźnik do wspomnianego fragmentu przez kanał. To skutecznie przenosi "własność" danych na docelowy czytnik kanału. Pamiętaj, że przeniesienie własności nie jest egzekwowane przez język ani środowisko wykonawcze, tylko przez konwencję.

Wciąż jesteś w stanie napisać do tej samej pamięci z dwóch goroutines, jeśli tak zdecydujesz. Innymi słowy: Go nie przeszkadza ci strzelać sobie w stopę, zapewnia jedynie semantykę językową, dzięki której błędy te są łatwiejsze do wykrycia.

Jeśli wartość zostanie przekazana do kanału, programista musi przyjąć, że wartość nie jest już jego do zapisania w tym samym goryle.

func F(c chan *T) { 
    // Create/load some data. 
    data := getSomeData() 

    // Send data into the channel. 
    c <- data 

    // 'data' should now be considered out-of-bounds for the remainder of 
    // this function. This is purely by convention, and is not enforced 
    // anywhere. For example, the following is still valid Go code, but will 
    // lead to problems. 
    data.Field = 123 
} 

Answer 2

Pytanie zakłada, że ​​pamięć współdzielona i obliczenia rozproszone są przeciwieństwami. To trochę jak pytanie: czy RAM i LAN są przeciwieństwem? Bardziej czytelne byłoby rozróżnienie współbieżności pamięci współdzielonej w węźle CPU/pamięci oraz między węzłami CPU/pamięci.

Jest to część szerszego obrazu badań nad przetwarzaniem równoległym. Było wiele projektów badawczych, w tym:

• rozwój komputerów non-Von-Neumann, które mają wiele procesorów dzieląc pojedynczy pamięci, połączonych jakąś formę przełączania tkaniny (często sieci Clos). OpenMP byłby odpowiedni dla nich.

• rozwijanie równoległych komputerów składających się z zestawu procesorów, z których każdy ma osobną pamięć, oraz z pewną siecią komunikacyjną między węzłami. Zazwyczaj jest to domem między innymi MPI.

Pierwszy przypadek specjalizuje się w braterstwie High Performance Computing. Jest to drugi przypadek znany większości z nas. W tym przypadku, zwykle w dzisiejszych czasach połączenie jest po prostu przez Ethernet, ale różne szybsze alternatywy o niższym opóźnieniu zostały (pomyślnie) opracowane dla pewnych nisz (np. IEEE1355 SpaceWire, które powstały z łączy szeregowych Transputer).

Przez wiele lat dominującym poglądem było to, że efektywna równoległość byłaby możliwa tylko wtedy, gdyby pamięć była dzielona, ​​ponieważ koszt komunikacji przekazywanych wiadomości był (naiwnie) uważany za zaporowy. W przypadku współbieżności pamięci współdzielonej trudność tkwi w oprogramowaniu: ponieważ wszystko jest współzależne, projektowanie współbieżności staje się kombinatorycznie trudniejsze i trudniejsze, gdy systemy stają się większe. Wymagana jest wiedza specjalistyczna.

Dla reszty z nas idziemy za Erlangiem, Limbo i oczywiście Ockhama w promowaniu przekazywania wiadomości jako środka do choreografii pracy do wykonania. Wynika to z algebry z Communicating Sequential Processes, która stanowi podstawę do tworzenia równoległych systemów o dowolnym rozmiarze.Projekty CSP są kompozycyjne: każdy podsystem może sam w sobie być składnikiem większego systemu, bez teoretycznego ograniczenia.

Twoje pytanie dotyczyło OpenMP (pamięć współużytkowana) i MPI (przekazywanie wiadomości rozproszonych), które mogą być używane razem. Go może być uważany za przybliżony odpowiednik MPI, ponieważ promuje przekazywanie wiadomości. Pozwala jednak również na blokadę i pamięć współdzieloną. Go różni się od MPI i OpenMP, ponieważ nie dotyczy bezpośrednio systemów wieloprocesorowych. Aby przejść do świata przetwarzania równoległego za pomocą Go, potrzebny byłby szkielet przekazujący sieć, taki jak OpenCL, dla którego ktoś pracuje nad API Go.