Szarym od mżawki świtem Wed, 04 Jun 2014 10:59:44 -0700, Piotrek wyrzucił
pustą ćwiartkę i oznajmił:

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

Co z wywołaniem main(), albo jedynej funkcji w main(), też mają być otoczone
lock/unlock()?

--
Edek

do góry

W dniu środa, 4 czerwca 2014 20:02:13 UTC+2 użytkownik Edek napisał:
> Szarym od mżawki świtem Wed, 04 Jun 2014 10:59:44 -0700, Piotrek wyrzucił
>
> pustą ćwiartkę i oznajmił:
>
>
>
> >> .... 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.
>
>
>
> Co z wywołaniem main(), albo jedynej funkcji w main(), też mają być otoczone
>
> lock/unlock()?
>
>
>
> --
>
> Edek

Teraz mi pewnie nie uwierzysz, ale poprzednią wiadomość wysyłałem
z myślą, że właśnie tym przykładem obalisz mój naiwny pomysł.
Oczywiście objęcie samego maina "lockami" kładłoby pozostałe
wątki na łopatki (bo nigdy nie doczekałyby się na swoją kolej),
ale spróbujmy obronić moje rozumowanie... e, nie, chyba jednak
się nie da :) Kusiło mnie, żeby spytać co by było, gdyby zrobić
wyjątek dla funkcji main() i pozwolić, żeby nie była
atomowa. Widzę jednak, że to by nic nie dało. Gdyby main()
nie była atomowa, ale atomowe byłoby wszystko to, co z niej wołamy,
mielibyśmy identyczny problem (bo wewnątrz main() mogłaby się znajdować
tylko jedna instrukcja albo jedną z wywoływanych funkcji byłaby
np. główna pętla programu i inne wątki bezowocnie czekałyby sobie
na jej zakończenie). Wniosek z tego taki, że to, co siedzi
w mainie, jednak nie może być defaultowo niepodzielne, więc
nie ma sensu, żeby cokolwiek innego takie było. Dziękuję
za pobudzenie do myślenia :)

do góry

Szarym od mżawki świtem Wed, 04 Jun 2014 12:10:14 -0700, Piotrek wyrzucił
pustą ćwiartkę i oznajmił:

> W dniu środa, 4 czerwca 2014 20:02:13 UTC+2 użytkownik Edek napisał:
>> Szarym od mżawki świtem Wed, 04 Jun 2014 10:59:44 -0700, Piotrek wyrzucił
>> > Teraz czekam na odpowiedź
>>
>> > dlaczego to jest niemożliwe do realizacji albo w niczym by nie pomogło.
>>
>>
>>
>> Co z wywołaniem main(), albo jedynej funkcji w main(), też mają być otoczone
>>
>> lock/unlock()?

>
> Teraz mi pewnie nie uwierzysz, ale poprzednią wiadomość wysyłałem
> z myślą, że właśnie tym przykładem obalisz mój naiwny pomysł.

Tak trochę podejrzewałem, ale odpowiedź wciąż jest ta sama :)

>Oczywiście objęcie samego maina "lockami" kładłoby pozostałe
> wątki na łopatki (bo nigdy nie doczekałyby się na swoją kolej),
> ale spróbujmy obronić moje rozumowanie... e, nie, chyba jednak
> się nie da :) Kusiło mnie, żeby spytać co by było, gdyby zrobić
> wyjątek dla funkcji main() i pozwolić, żeby nie była
> atomowa. Widzę jednak, że to by nic nie dało. Gdyby main()
> nie była atomowa, ale atomowe byłoby wszystko to, co z niej wołamy,
> mielibyśmy identyczny problem (bo wewnątrz main() mogłaby się znajdować
> tylko jedna instrukcja albo jedną z wywoływanych funkcji byłaby
> np. główna pętla programu i inne wątki bezowocnie czekałyby sobie
> na jej zakończenie). Wniosek z tego taki, że to, co siedzi
> w mainie, jednak nie może być defaultowo niepodzielne, więc
> nie ma sensu, żeby cokolwiek innego takie było. Dziękuję
> za pobudzenie do myślenia :)

Fajnie byłoby, gdyby ktoś rozwiązał ten problem (z OP). Wszystkie
rozwiązania "doklejone" do imperatywnego programowania owszem działają,
ale nie są idealne.

Kiedyś nawet zacząłem tworzyć język, który by był fajny i się "sam"
zrównoleglał na cpu i gpu, ale poległem na teorii i prozaicznym braku
czasu. Jeżeli cię interesuje temat, istnieją takie języki, gdzie rozwiązanie
jest dużo prostsze, tylko po co uczyć się niepopularnego języka. Powstały
też narzędzia takie jak Ocelot czy LLVM dla PTX Nvidii, co ułatwia
implementację, co też oznacza że będziemy mieli rozwiązanie,
kwestia czasu [1]. Ktoś z "POTĘGI INFORMATYCZNEJ" mógłby pokazać klasę...

[1] Wystarczy mieć rozwiązanie wypluwające llvm IR, co znacznie ułatwia
implementację.

--
Edek

do góry