Wyjaśnijcie mi taką jedną rzecz. Niby mam ogólne,
teoretyczne pojęcie o wielowątkowości - wiem z czym
to się je, jakie problemy wiążą się z programowaniem
wielowątkowym, ale zawsze zastanawiała mnie taka jedna
fundamentalna kwestia: dlaczego programiści w ogóle muszą
być świadomi tego, że programują wielowątkowo, tzn. dlaczego
samodzielnie muszą używać muteksów i innych mechanizmów
synchronizacji wątków? Może bredzę, ale nie dałoby się tego
jakoś rozwiązać na poziomie samego języka? Dlaczego każda
instrukcja programu nie jest domyślnie atomowa, tzn. kompilator
przy generowaniu kodu sam nie emuluje atomowości
wstawiając gdzie trzeba różne locki/unlocki tak, żeby
w ogóle nie trzeba było o tym myśleć? Chodzi o to, że
byłoby to niewydajne?

do góry

On 24/05/2014 12:29, Piotrek wrote:
> Wyjaśnijcie mi taką jedną rzecz. Niby mam ogólne,
> teoretyczne pojęcie o wielowątkowości - wiem z czym
> to się je, jakie problemy wiążą się z programowaniem
> wielowątkowym, ale zawsze zastanawiała mnie taka jedna
> fundamentalna kwestia: dlaczego programiści w ogóle muszą
> być świadomi tego, że programują wielowątkowo, tzn. dlaczego
> samodzielnie muszą używać muteksów i innych mechanizmów
> synchronizacji wątków? Może bredzę, ale nie dałoby się tego
> jakoś rozwiązać na poziomie samego języka? Dlaczego każda
> instrukcja programu nie jest domyślnie atomowa, tzn. kompilator
> przy generowaniu kodu sam nie emuluje atomowości
> wstawiając gdzie trzeba różne locki/unlocki tak, żeby
> w ogóle nie trzeba było o tym myśleć? Chodzi o to, że
> byłoby to niewydajne?

W Erlangu, Haskellu czy Go możesz spokojnie pisać programy wykonujące
się na wielu wątkach bez żadnego grzebania w lockach.

Jeśli chodzi konkretnie o programowanie imperatywne z dzieleniem stanu,
to również istnieją biblioteki pozwalające na ominięcie problemu jawnego
używania locków, ale oczywiście samo użycie nie gwarantuje braku data
races w programie. To, co proponujesz rzeczywiście byłoby niewydajne -
nawet tam, gdzie architektura gwarantuje atomowość pewnych operacji (np.
zapisu lub odczytu słowa maszynowego) optymalizacje procesora powodują
że poszczególne atomowe operacje mogą być widoczne w różnej kolejności z
różnych wątków. O większych operacjach, gdzie kompilator musiałby
zakładać locka za każdym razem, kiedy instrukcja języka przekłada się na
więcej niż jedną instrukcję procesora już lepiej nie mówić. Przede
wszystkim jednak nie rozwiązuje to problemu: kompilator nadal nie wie,
co jest atomową instrukcją z punktu widzenia semantyki twojego programu.
Wyobraź sobie np. że masz taką strukturę jak lista dwukierunkowa.
Operacje jak wstawienie czy usunięcie elementu wymagają kilku operacji
odczytania i zapisania wskaźników. Nawet jeśli każda z tym operacji na
wskaźnikach jest atomowa, a nawet jeśli kompilator zadbał żeby np.
skopiowanie wartości wskaźnika było atomową operacją, to nadal (jeśli
nie zaznaczysz tego jakoś w programie) kompilator nie ma podstaw żeby
uważać, że tych kilka kopiowań wskaźników jest również operacją atomową
- to ty wiesz, że implementujesz listę dwukierunkową, kompilator tego
nie wie. I oczywiście jeśli same kopiowania są atomowe, ale całe
wstawienie/usunięcie elementu nie jest, to masz data race: co by się
działo jakby w połowie wstawiania elementu do listy przez jeden wątek
drugi postanowił wykonać inną operację - np. usunąć poprzedzający
element? Oczywiście tak w ogóle da się zdefiniować listę z zaznaczeniem
co jest atomową operacją bez jawnego używania locków - poczytaj sobie
np. o monitorach.

do góry

On 2014-05-24, Piotrek <p...@p...onet.pl> wrote:
> Wyjaśnijcie mi taką jedną rzecz. Niby mam ogólne,
> teoretyczne pojęcie o wielowątkowości - wiem z czym
> to się je, jakie problemy wiążą się z programowaniem
> wielowątkowym, ale zawsze zastanawiała mnie taka jedna
> fundamentalna kwestia: dlaczego programiści w ogóle muszą
> być świadomi tego, że programują wielowątkowo, tzn. dlaczego
> samodzielnie muszą używać muteksów i innych mechanizmów
> synchronizacji wątków? Może bredzę, ale nie dałoby się tego
> jakoś rozwiązać na poziomie samego języka? Dlaczego każda
> instrukcja programu nie jest domyślnie atomowa, tzn. kompilator
> przy generowaniu kodu sam nie emuluje atomowości
> wstawiając gdzie trzeba różne locki/unlocki tak, żeby
> w ogóle nie trzeba było o tym myśleć? Chodzi o to, że
> byłoby to niewydajne?

Nie. Chodzi o to, że nie wystarczy aby *instrukcja* ma być atomowa. Cała
*sekwencja* instrukcji ma być niepodzielna.

Ale pamięć współdzielona to nie jest jedyny model obliczeń
współbieżnych. Jest też model przesyłania komunikatów -- wtedy masz
mnóstwo obliczeń jednowątkowych, które tylko wymieniają się ze sobą
danymi i nie ma problemu z jednoczesnym dostępem do zasobów.

--
Secunia non olet.
Stanislaw Klekot

do góry

On Sat, 24 May 2014 04:29:43 -0700 (PDT), Piotrek
<p...@p...onet.pl> wrote:

>Wyjaśnijcie mi taką jedną rzecz. Niby mam ogólne,
>teoretyczne pojęcie o wielowątkowości - wiem z czym
>to się je, jakie problemy wiążą się z programowaniem
>wielowątkowym, ale zawsze zastanawiała mnie taka jedna
>fundamentalna kwestia: dlaczego programiści w ogóle muszą
>być świadomi tego, że programują wielowątkowo, tzn. dlaczego
>samodzielnie muszą używać muteksów i innych mechanizmów
>synchronizacji wątków?

Dlatego ze kompilator za programiste programu nei napisze

A.L.

do góry

W dniu sobota, 24 maja 2014 13:29:43 UTC+2 użytkownik Piotrek napisał:
> Wyjaśnijcie mi taką jedną rzecz. Niby mam ogólne,
>
> teoretyczne pojęcie o wielowątkowości - wiem z czym
>
> to się je, jakie problemy wiążą się z programowaniem
>
> wielowątkowym, ale zawsze zastanawiała mnie taka jedna
>
> fundamentalna kwestia: dlaczego programiści w ogóle muszą
>
> być świadomi tego, że programują wielowątkowo, tzn. dlaczego
>
> samodzielnie muszą używać muteksów i innych mechanizmów
>
> synchronizacji wątków? Może bredzę, ale nie dałoby się tego
>
> jakoś rozwiązać na poziomie samego języka? Dlaczego każda
>
> instrukcja programu nie jest domyślnie atomowa, tzn. kompilator
>
> przy generowaniu kodu sam nie emuluje atomowości
>
> wstawiając gdzie trzeba różne locki/unlocki tak, żeby
>
> w ogóle nie trzeba było o tym myśleć? Chodzi o to, że
>
> byłoby to niewydajne?

wydaje mi sie ze da sie wypracowac pewne wzorce pisania (sposoby kodowania) tak ze
stosowanie ledwie kilku z nich zalatwialoby przewazajaca wiekszosc przypadków - ja
bym to robil (przynajmniej w wiekszosci) na poziomie modulowym (intermodułowym),
taki moduł asynchroniczny i inne tego typu sprawy -

w programowaniu jst chyba tak ze zasadniczo pewnie program mozn anaisac na miriad
soposobow, ale tez wysraczy wtbrac kilka kluczowych 'wzorców'/elementów i napisac
pozniej wlasciwie wszystko za ich pomocą
(to samo zdaje sie dotyczy programowania wielowatkowego)

- tylko trzeba sie nauczyc tych wzorców; malo co pisze wielowatkowo ostatnio (juz z
pol roku temu na
probe przepisywalem na dwa watki prosty raytracer - w sumie moglbym przemyslac jak to
uogólnic

do góry

> probe przepisywalem na dwa watki prosty raytracer - w sumie moglbym przemyslac jak
to uogólnic

na przyklad w tym raytracerze byla funkcja

rander(rect);

cos w tym stylu, mozna zrównoleglic po prostu
przez wywoalnie rownolegle na paru malych rectach
zamiast na jednym dużym

ta funkcja 'render' (fibra jak ja to na wlasny uzytek czasem nazywam) obejmuje
dobrych kilkanascie roboczych podfunkcji, ogolnie
czyta dane sceny jest to ew dzilone ale wylacznie read only, pisze tez do danego
prostokata obrazu rw lub write only ale nie dzielone i uzywa tez
jakiejs dozy danych roboczych, ktore powinny byc klonowane dla kazdego watku

pewnie mozna sie dopatrzec tutaj pewnego wzorca
ktory mozna troche uogólnic, taką fibrę dostosowanądo tego by robic ew równoległa
robote
na cześci 'obszaru' moglbym np nazwac partial workerem, drugim skladniekiem mozna
nazwac tego prostego managera ktory podzili obszar i wywola tych partial-workerów

wczesniej rozmyalalem cos i pisalem o innych tego typu wzorcach np kiedys o tych
ukladach producent konsument krote o ile pamietam wyszlo mozna uzywac
chyba wogole bez locków (teraz zapomnialem jak to
dokladnie mialo chodzic), jak rowniez o tych modulach asynchronicznych i ze dwu
jeszcze innych rzeczach

do góry

On Sat, 24 May 2014 13:43:07 -0500, A.L. <a...@a...com> wrote:
> Dlatego ze kompilator za programiste
> programu nei napisze

Kwestia definicji "napisać program". Nota bene, lepiej używać
"stworzyć program". Bo niektóre programy się rysuje itd. Ponieważ
"twórczość" jest właściwa tylko istotom rozumnym, to masz rację.

W praktyce? Zapomniałem o czymś takim jak automatyczne generowania
kodu źródłowego.

do góry

Szarym od mżawki świtem Sat, 24 May 2014 04:29:43 -0700, Piotrek wyrzucił
pustą ćwiartkę i oznajmił:

> Wyjaśnijcie mi taką jedną rzecz. Niby mam ogólne,
> teoretyczne pojęcie o wielowątkowości - wiem z czym
> to się je, jakie problemy wiążą się z programowaniem
> wielowątkowym, ale zawsze zastanawiała mnie taka jedna
> fundamentalna kwestia: dlaczego programiści w ogóle muszą
> być świadomi tego, że programują wielowątkowo, tzn. dlaczego
> samodzielnie muszą używać muteksów i innych mechanizmów
> synchronizacji wątków? Może bredzę, ale nie dałoby się tego
> jakoś rozwiązać na poziomie samego języka? Dlaczego każda
> instrukcja programu nie jest domyślnie atomowa, tzn. kompilator
> przy generowaniu kodu sam nie emuluje atomowości
> wstawiając gdzie trzeba różne locki/unlocki tak, żeby
> w ogóle nie trzeba było o tym myśleć? Chodzi o to, że
> byłoby to niewydajne?

Fajnie byłoby, gdyby się dało, ale nie istnieje takie rozwiązanie.

Są zbliżone, takie jak model przekazywania wiadomości - ma swoje
plusy i minusy, ale nie wymaga jawnej synchornizacji, co nie znaczy,
że na nic nie trzeba uważać. Zbliżona do celu jest pamięć transakcyjna,
(prawie) moóżna jej używać tak jak napisałeś, prawie, bo i tak trzeba
zaznaczyć granice transakcji i ewentualnie podtransakcji.

W praktyce gdybyś mógł przedstawić przedstawić coś co byłoby
spójne na pewno znajdzie się ktoś kto takie rozwiązanie zaimplementuje.
Szczegóły techniczne zostawiając na później, pierwsze pytanie:
skąd kompilator ma wiedzieć o co programiście chodzi? Najlepiej
z przykładami, skoro

> Dlaczego każda
> instrukcja programu nie jest domyślnie atomowa, tzn. kompilator
> przy generowaniu kodu sam nie emuluje atomowości
> wstawiając gdzie trzeba różne locki/unlocki tak, żeby
> w ogóle nie trzeba było o tym myśleć?

.... powiedz, jak kompilator miałby zrozumieć

a = b + c

a) osobno odczyt zmiennych dodawanie i zapis?
b) całe wyrażenie wraz z przypisaniem atomowo?
c) co jeżeli typem jest liczba zespolona, czy w klasie Complex
musi być informacja, że część rzeczywistą i urojoną traktuje się
atomowo czyli zawsze razem, czy może kompilator też miałby się
tego w jakiś sposób "domyśleć"?
d) ?

--
Edek

do góry

Piotrek <p...@p...onet.pl> wrote:

> fundamentalna kwestia: dlaczego programiści w ogóle muszą
> być świadomi tego, że programują wielowątkowo, tzn. dlaczego
> samodzielnie muszą używać muteksów i innych mechanizmów
> synchronizacji wątków?

google://openmp

--
SELECT finger FROM hand WHERE id = 3;
http://www.chmurka.net/

do góry

> .... powiedz, jak kompilator miałby zrozumieć
>
>
>
> a = b + c
>
>
>
> a) osobno odczyt zmiennych dodawanie i zapis?
>
> b) całe wyrażenie wraz z przypisaniem atomowo?
>
> c) co jeżeli typem jest liczba zespolona, czy w klasie Complex
>
> musi być informacja, że część rzeczywistą i urojoną traktuje się
>
> atomowo czyli zawsze razem, czy może kompilator też miałby się
>
> tego w jakiś sposób "domyśleć"?

Wybieram odpowiedź b), tzn. całe wyrażenie jest traktowane
jako jedna, niepodzielna instrukcja, niezależnie od tego na jakich typach
danych wykonywana jest nasza przykładowa operacja. Generalnie załóżmy,
że kompilator dowolną instrukcję języka traktuje jako niepodzielną
całość niezależnie od jej stopnia złożoności, tzn. tłumaczy ją na kod
maszynowy, po czym "obudowuje" ją jakąś parą lock/unlock tak, żeby była
atomowa. Nieważne czy ta instrukcja to np. zwiększenie liczby o 1,
czy wywołanie jakiejś skomplikowanej funkcji. Teraz czekam na odpowiedź
dlaczego to jest niemożliwe do realizacji albo w niczym by nie pomogło.

do góry