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