On 23/06/2013 19:42, Michoo wrote:
>
>> Proponuje to zrobic przy pomocy mutexow lub nawet cmpxchg.
>
> A myślisz, że co niby leży "pod spodem" kolejek komunikatów? W javie
> wszystkie synchronized() to jest właśnie na x86 cmpxchg.

Pomijając wszystko inne, czy twierdzisz, że instrukcja procesora cmpxch
potrafi wykonać czynność "wstrzymaj wykonanie wątku do momentu..."? Jak
to się niby odbywa - przecież wątek jest bytem funkcjonującym na
poziomie co najmniej systemu operacyjnego (jeśli nie wręcz maszyny
wirtualnej)?

do góry

W dniu niedziela, 23 czerwca 2013 22:25:56 UTC+2 użytkownik Andrzej Jarzabek napisał:
> On 23/06/2013 19:42, Michoo wrote:
>
> >
>
> >> Proponuje to zrobic przy pomocy mutexow lub nawet cmpxchg.
>
> >
>
> > A myślisz, że co niby leży "pod spodem" kolejek komunikatów? W javie
>
> > wszystkie synchronized() to jest właśnie na x86 cmpxchg.
>
>
>
> Pomijając wszystko inne, czy twierdzisz, że instrukcja procesora cmpxch
> potrafi wykonać czynność "wstrzymaj wykonanie wątku do momentu..."? Jak
> to się niby odbywa - przecież wątek jest bytem funkcjonującym na
> poziomie co najmniej systemu operacyjnego (jeśli nie wręcz maszyny
> wirtualnej)?


potrzebna jest jeszcze funkcja suspend_() ktora
przerzuci procesor na kolejny watek i ta funkcja
chyba nie musi byc chyba zbyt skomplikowana
- kiedys nalezaloby napisac sobie na sucho
kod takiego schedulera by ocenic jak wydajne to
moze byc (ale to musialbym byc mniej wykonczony
niz teraz by zajmowac sie takimi pobocznymi
rzeczami)

do góry

Dnia Sun, 23 Jun 2013 13:55:26 -0700 po głębokim namyśle firr rzekł:

> W dniu niedziela, 23 czerwca 2013 22:25:56 UTC+2 użytkownik Andrzej
> Jarzabek napisał:
>> On 23/06/2013 19:42, Michoo wrote:
>> > A myślisz, że co niby leży "pod spodem" kolejek komunikatów? W javie
>>
>> > wszystkie synchronized() to jest właśnie na x86 cmpxchg.
>>
>>
>>
>> Pomijając wszystko inne, czy twierdzisz, że instrukcja procesora cmpxch
>> potrafi wykonać czynność "wstrzymaj wykonanie wątku do momentu..."? Jak
>> to się niby odbywa - przecież wątek jest bytem funkcjonującym na
>> poziomie co najmniej systemu operacyjnego (jeśli nie wręcz maszyny
>> wirtualnej)?
>
>
> potrzebna jest jeszcze funkcja suspend_() ktora przerzuci procesor na
> kolejny watek i ta funkcja chyba nie musi byc chyba zbyt skomplikowana -
> kiedys nalezaloby napisac sobie na sucho kod takiego schedulera by
> ocenic jak wydajne to moze byc (ale to musialbym byc mniej wykonczony
> niz teraz by zajmowac sie takimi pobocznymi rzeczami)

Megaglabiada, człowieku orkiestro. Ty się po prostu nie nadajesz.

--
Edek

do góry

On 23.06.2013 22:25, Andrzej Jarzabek wrote:
> On 23/06/2013 19:42, Michoo wrote:
> >
>>> Proponuje to zrobic przy pomocy mutexow lub nawet cmpxchg.
>>
>> A myślisz, że co niby leży "pod spodem" kolejek komunikatów? W javie
>> wszystkie synchronized() to jest właśnie na x86 cmpxchg.
>
> Pomijając wszystko inne, czy twierdzisz, że instrukcja procesora cmpxch
> potrafi wykonać czynność "wstrzymaj wykonanie wątku do momentu..."?

Oczywiście, że nie. Instrukcja ta pozwala na dwie rzeczy(mówimy o SMP):
- możliwie bezkosztowe (kilka cykli) uzyskanie blokady na wyłączność
(wejście do sekcji krytycznej)
- możliwie bezkosztowe wstawianie/usuwanie obiektów z kolejek

> Jak
> to się niby odbywa - przecież wątek jest bytem funkcjonującym na
> poziomie co najmniej systemu operacyjnego (jeśli nie wręcz maszyny
> wirtualnej)?

W pierwszym przypadku jest polecam lekturę tego jak działają linuxowe
FUTEXy. W skrócie chodzi o to, żeby w domyślnej ścieżce wykonania (gdy
sekcja krytyczna jest wolna) nie wykonywać drogich odwołań do systemu
operacyjnego. Gdy wątek musi i tak czekać to można sobie pozwolić na
trochę dłuższą ścieżkę wykonania (i wtedy prosi system operacyjny o
uśpienie).

W drugim przypadku możemy mieć kolejkę producent(ci)->konsument(ci)
która nie wymaga blokowania ("lock-free") a więc oszczędzamy całkiem
sporo czasu na usypianiu i budzeniu wątków.

--
Pozdrawiam
Michoo

do góry

Dnia Sun, 23 Jun 2013 20:42:02 +0200 po głębokim namyśle Michoo rzekł:

> A myślisz, że co niby leży "pod spodem" kolejek komunikatów? W javie
> wszystkie synchronized() to jest właśnie na x86 cmpxchg.

Z tego co mi wiadomo, Java używa w tym celu mechanizmów OS. Na linuksie
faktycznie są to futexy, ale na innych YMMV.

--
Edek

do góry

On Sun, 23 Jun 2013 20:42:02 +0200, Michoo <m...@v...pl> wrote:

>On 23.06.2013 18:35, A.L. wrote:
>>> Praktycznie ze względów wydajnościowych stosuje się tam gdzie to
>>> dostępne cmpxchg.
>>
>> Ja uzywalem przez dluzszy czas JCSMP.
>
>Nie znam i google też milczy.
>
>> To jest Javowa implemenatcja CSP
>> (Communication Sequential Processes) Hoare.
>
>JCSP?

JCSP

>
>> Nie pamietam dokladnie,
>> ale w ostatnim projekcie bylo cos 200 procesow i ponad 400 kanalow.
>
>Mam być pod wrażeniem? Nie jestem.
>

Gratulacje. Rozumiem ze dla Kolegi to pestka

>>
>> Proponuje to zrobic przy pomocy mutexow lub nawet cmpxchg.
>
>A myślisz, że co niby leży "pod spodem" kolejek komunikatów? W javie
>wszystkie synchronized() to jest właśnie na x86 cmpxchg.
>
>
>Oczywiste jest, że istnieją wygodne wysokopoziomowe sposoby na radzenie
>sobie z wielowątkowością(choćby lubiane prze mnie producent-konsument
>albo reaktor), ale koniec końców "na dnie" synchronizacja zazwyczaj jest
>robiona flagą a nie muteksem.

Co mnie obchodzi co jest "na dnie"?... Czy Kolega proponuje ze
neizbednym nazredziem programisty powinan byc lutownica? Ja pamietem
te czasy, ale na szczescie odeszly w niebyt.

A.L.

do góry

On 23/06/2013 23:21, Michoo wrote:
> On 23.06.2013 22:25, Andrzej Jarzabek wrote:
>
>> Pomijając wszystko inne, czy twierdzisz, że instrukcja procesora cmpxch
>> potrafi wykonać czynność "wstrzymaj wykonanie wątku do momentu..."?
>
> Oczywiście, że nie.
[...]

Dziękuję.

>> Jak
>> to się niby odbywa - przecież wątek jest bytem funkcjonującym na
>> poziomie co najmniej systemu operacyjnego (jeśli nie wręcz maszyny
>> wirtualnej)?
>
> W pierwszym przypadku jest polecam lekturę tego jak działają linuxowe
> FUTEXy.
[...]

WIem jak działają.

> W drugim przypadku możemy mieć kolejkę producent(ci)->konsument(ci)
> która nie wymaga blokowania ("lock-free") a więc oszczędzamy całkiem
> sporo czasu na usypianiu i budzeniu wątków.

Chodziło mi o to, że samymi atomowymi instrukcjami nie zapewnisz tego,
co z definicji ma mieć javowe synchronized - usypianie i budzenie
wątków. Musisz mieć wsparcie systemu operacyjnego i tyle. To, że
istnieją optymalizacje pozwalające odwoływać się do tego systemu
rzadziej to miłe, ale niezmienia zasadniczego problemu - pod spodem masz
skomplikowaną maszynerięę, której CMPXCHG (lub inne atomowe instrukcje)
są częścią.

do góry

W dniu poniedziałek, 24 czerwca 2013 07:34:27 UTC+2 użytkownik Andrzej Jarzabek
napisał:
> On 23/06/2013 23:21, Michoo wrote:
>
> > On 23.06.2013 22:25, Andrzej Jarzabek wrote:
>
> >
>
> >> Pomijając wszystko inne, czy twierdzisz, że instrukcja procesora cmpxch
>
> >> potrafi wykonać czynność "wstrzymaj wykonanie wątku do momentu..."?
>
> >
>
> > Oczywiście, że nie.
>
> [...]
>
>
>
> Dziękuję.
>
>
>
> >> Jak
>
> >> to się niby odbywa - przecież wątek jest bytem funkcjonującym na
>
> >> poziomie co najmniej systemu operacyjnego (jeśli nie wręcz maszyny
>
> >> wirtualnej)?
>
> >
>
> > W pierwszym przypadku jest polecam lekturę tego jak działają linuxowe
>
> > FUTEXy.
>
> [...]
>
>
>
> WIem jak działają.
>
>
>
> > W drugim przypadku możemy mieć kolejkę producent(ci)->konsument(ci)
>
> > która nie wymaga blokowania ("lock-free") a więc oszczędzamy całkiem
>
> > sporo czasu na usypianiu i budzeniu wątków.
>
>
>
> Chodziło mi o to, że samymi atomowymi instrukcjami nie zapewnisz tego,
>
> co z definicji ma mieć javowe synchronized - usypianie i budzenie
>
> wątków. Musisz mieć wsparcie systemu operacyjnego i tyle. To, że
>
> istnieją optymalizacje pozwalające odwoływać się do tego systemu
>
> rzadziej to miłe, ale niezmienia zasadniczego problemu - pod spodem masz
>
> skomplikowaną maszynerięę, której CMPXCHG (lub inne atomowe instrukcje)
>
> są częścią.

to sie nawet zgadza (ze cmpxchg moze byloby z 1/1000
calej operacji) ale tez chyba nie az tak
skomplikowaną operacje

kazdy watek ma swoj stan obejmujacy jakis przydział ram i ten stan chyba nie ulega
zmianom, w momencie
przerzucania watkow trzeba pewnie zrzucic rejestry i
podniesc te zrzucone przez poprzedni watek, i wsio
(?) - mogloby byc jako tako szybko

nieststy obawiam sie jak zwykle ze sysstemy operacyjne costam ew chrzanią i jest to
jakostam
rozbudowane i muli

potrzebna jest informacja jak wiele jakichs nieoszukanych pelnych przelaczen na
sekunde
moze wydolic dany system (jak byloby to milion
to w miare ok, jak wiecej jak milion jeszcze
lepiej ale jak mniej to nie tak dobrze)

do góry

On 24.06.2013 03:41, A.L. wrote:
> On Sun, 23 Jun 2013 20:42:02 +0200, Michoo<m...@v...pl> wrote:

>>
>>> Nie pamietam dokladnie,
>>> ale w ostatnim projekcie bylo cos 200 procesow i ponad 400 kanalow.
>>
>> Mam być pod wrażeniem? Nie jestem.
>>
>
> Gratulacje. Rozumiem ze dla Kolegi to pestka

Nie powiedziałem tego - wygląda na parę miesięcy solidnej,
rzemieślniczej pracy. Tylko to nic nie wnosi do dyskusji.

>
>>>
>>> Proponuje to zrobic przy pomocy mutexow lub nawet cmpxchg.
>>
>> A myślisz, że co niby leży "pod spodem" kolejek komunikatów? W javie
>> wszystkie synchronized() to jest właśnie na x86 cmpxchg.
>>
>>
>> Oczywiste jest, że istnieją wygodne wysokopoziomowe sposoby na radzenie
>> sobie z wielowątkowością(choćby lubiane prze mnie producent-konsument
>> albo reaktor), ale koniec końców "na dnie" synchronizacja zazwyczaj jest
>> robiona flagą a nie muteksem.
>
> Co mnie obchodzi co jest "na dnie"?...

Dyskusja dotyczyła podstawowego elementu synchronizacji. Semafor Dijskry
nie jest prostszy niż semafor binarny o semantyce test-and-set (który ma
wsparcie sprzętowe na większości współczesnych maszyn) a ma pewne
istotne wady (jak brak gwarancji na zagłodzenie). W praktyce implantacja
semafora _wymaga_ więc listy procesów oczekujących.

A tak ładnie wyglądające w teorii komunikowanie liczby elementów w
kanale za pomocą odpowiednich ilości p i v w praktyce znacznie ładniej i
mniej błędogennie wychodzi w kombinacji put i blokującego get lub
nieblokującego try-get.

> Czy Kolega proponuje ze
> neizbednym nazredziem programisty powinan byc lutownica?

Zależy co się programuje - czasami tak.

> Ja pamietem
> te czasy, ale na szczescie odeszly w niebyt.

Jestem właśnie po maratonie z javą - klientom się kończyły zasoby. "W
dawnych czasach" nikt by nawet nie pomyślał o alokowaniu w sumie
kilkunastu milionów obiektów wewnątrz procedury porównującej mergesorta
po to aby sprawdzić czy dwie daty wskazują na ten sam dzień.

--
Pozdrawiam
Michoo

do góry

On Thu, 27 Jun 2013 22:33:02 +0200, Michoo <m...@v...pl> wrote:

>
>Dyskusja dotyczyła podstawowego elementu synchronizacji. Semafor Dijskry
>nie jest prostszy niż semafor binarny o semantyce test-and-set (który ma
>wsparcie sprzętowe na większości współczesnych maszyn) a ma pewne
>istotne wady (jak brak gwarancji na zagłodzenie). W praktyce implantacja
>semafora _wymaga_ więc listy procesów oczekujących.
>

Obawiam sie ze nie zrozumiemy sie.

>A tak ładnie wyglądające w teorii komunikowanie liczby elementów w
>kanale za pomocą odpowiednich ilości p i v w praktyce znacznie ładniej i
>mniej błędogennie wychodzi w kombinacji put i blokującego get lub
>nieblokującego try-get.
>

Obawiam sie ze nei zrozumiemy sie. Chyba operujemny na roznych
poziomach abstrakcji. I roznych poziomach praktyki.

>Jestem właśnie po maratonie z javą - klientom się kończyły zasoby. "W
>dawnych czasach" nikt by nawet nie pomyślał o alokowaniu w sumie
>kilkunastu milionów obiektów wewnątrz procedury porównującej mergesorta
>po to aby sprawdzić czy dwie daty wskazują na ten sam dzień.

Idioci byli zawsze - tylko stopien idiotyzmu byl (i jest)
proporcjonalny do spzretowych mozliwosci

P.S. Zadam to samo zadanko co kiedys: procesy a, b, c, d, e, f

Wzajemne wykluczanie: (a,c), (c,f), (a,b), (b,e), (b,d), (c,d), (e,f)

Zaprojeltowac rozwiazanie bez deadlocku i starvation free

do góry