W dniu 2012-02-20 14:28, Wojciech Jaczewski pisze:
> Wojciech Muła wrote:
>
>> W dniu poniedziałek, 20 lutego 2012, 11:12:25 UTC+1 użytkownik Wojciech
>> Jaczewski napisał:
>>> A. L. wrote:
>>>
>>>> [...] "ale ja bez watkow". Na pytanie "dlaczego" padaja rozne
>>>> [odpowiedzi. ...] "to jest sposob na klopoty"
>>>
>>> A czy przypadkiem używanie wątków (tam gdzie nie jest to na prawdę
>>> niezbędne) nie jest proszeniem się o kłopoty?
>>
>> Raczej problem polega na tym, że przepytywani nie potrafiliby uzasadnić
>> dlaczego. :)
>
> Co wcale nie znaczy, że nie wiedzą. Jeśli są programistami, a nie
> wykładowcami, nie powinno to być problemem.
> Nawet głupie pomysły mogą być bardzo "mądre", dopóki się tylko o nich mówi,
> a nie zacznie się ich wcielać w życie. Odwrotna sytuacja też występuje - nie
> udaje się stworzyć pięknego uzasadnienia, a sam pomysł jest dobry.


Ale jeśli robią wrażenie, że sami właściwie nie wiedzą dlaczego.
Wtedy przepytujący może to zrozumieć jako 'nie chciało mi się
ale się nie przyznam' ;)

Z drugiej strony niektórzy popadają w znacznie gorsza drugą
skrajność. Autoprezentacja ważniejsza od umiejętności:/

pzdr
bartekltg

do góry

On Mon, 20 Feb 2012 11:12:25 +0100, Wojciech Jaczewski
<w...@o...pl> wrote:

>A. L. wrote:
>
>> [...] "ale ja bez watkow". Na pytanie "dlaczego" padaja rozne odpowiedzi.
>> [...] "to jest sposob na klopoty"
>
>A czy przypadkiem używanie wątków (tam gdzie nie jest to na prawdę
>niezbędne) nie jest proszeniem się o kłopoty?

Kolega zartuje, prawda?.. .Ale to taki sobie zart...

A.L.

do góry

A. L. wrote:

>>A czy przypadkiem używanie wątków (tam gdzie nie jest to na prawdę
>>niezbędne) nie jest proszeniem się o kłopoty?
>
> Kolega zartuje, prawda?..

Nie.
Lubisz odsyłanie do książek... W kwestii wątków zgadzam się z "The Art of
Unix programming". Zacząłem miec takie samo zdanie jak autorzy jeszcze zanim
na tę książkę trafiłem.

do góry

Michoo wrote:

> W dniu 20.02.2012 11:12, Wojciech Jaczewski pisze:
>> A. L. wrote:
>>
>>> [...] "ale ja bez watkow". Na pytanie "dlaczego" padaja rozne
>>> [odpowiedzi. ...] "to jest sposob na klopoty"
>>
>> A czy przypadkiem używanie wątków (tam gdzie nie jest to na prawdę
>> niezbędne) nie jest proszeniem się o kłopoty?
> Abstrahując od niedouczonych programistów, którzy sobie z wątkami nie
> radzą (niestety bardzo częste) to jakie kłopoty są możliwe?

Jeśliby sobie wypisać wszystkie możliwe stany, w jakich może znaleźć się
program wielowątkowy a w jakich jednowątkowy, to w wielowątkowym będzie ich
znacznie więcej. Z tego w część z nich program będzie wchodził niezwykle
rzadko (np. tylko przy obciążonym na 100% systemie) - co znacznie utrudni
wychwycenie niektórych błędów.

> Imo wątki nie dość, że zazwyczaj upraszczają zapis

Kosztem dłuższego analizowania/testowania, czy gdzieś nie ma wyścigu.

> (bo zazwyczaj
> wymuszają model oparty o message passing) to jeszcze pozwalają na
> łatwiejsze zmiany.

Wolę message passing na procesach.
Częściowo wynika to z tego, co dotychczas robiłem, a POSIX-owe API ma bardzo
poważne - jak dla mnie - wady:
- pthread_cond_timedwait operuje na czasie systemowym a nie monotonicznym
- nie mam możliwości nastawić czekania (select/poll) na pierwsze ze zdarzeń:
cond (lub semafor), otrzymanie danych na socket-cie.
A skoro zwykle i tak muszę używać komunikacji przez potok lub gniazdo, to
wolę osobny proces zamiast wątku.

do góry

W dniu 20.02.2012 15:06, Wojciech Jaczewski pisze:
> Michoo wrote:
>
>
>> Imo wątki nie dość, że zazwyczaj upraszczają zapis
>
> Kosztem dłuższego analizowania/testowania, czy gdzieś nie ma wyścigu.

Jak zakładasz możliwość istnienia wyścigu to znaczy, że problem jest na
tyle złożony, że i tak będzie dużo analizowania i testowania.

Ja mówię o imo najsensowniejszym układzie w większości przypadków:
- producent/ci generujący zdarzenia przetwarzania
- konsument/ci generujący wynik i ewentualne zdarzenia odpowiedzi(np
większość GUI pozwala na wywołania tylko z wątku głównego)
- cały kontekst enkapsulowany w żądaniu/odpowiedzi.

>
>> (bo zazwyczaj
>> wymuszają model oparty o message passing) to jeszcze pozwalają na
>> łatwiejsze zmiany.
>
> Wolę message passing na procesach.
Procesy są dość ciężkie - przekazanie złożonych obiektów niepotrzebnie
trwa. A tu sprawdzasz czy na pewno ref_count jest równy 1, odpalasz i
zapominasz.


> Częściowo wynika to z tego, co dotychczas robiłem, a POSIX-owe API ma bardzo
> poważne - jak dla mnie - wady:
> - pthread_cond_timedwait operuje na czasie systemowym a nie monotonicznym
> - nie mam możliwości nastawić czekania (select/poll) na pierwsze ze zdarzeń:
> cond (lub semafor), otrzymanie danych na socket-cie.
> A skoro zwykle i tak muszę używać komunikacji przez potok lub gniazdo, to
> wolę osobny proces zamiast wątku.
Ok. Ale to już specyfika problemu.

A ja piszę, że ogólnie o ile ktoś wie jak je używać to wątki są dobre.

--
Pozdrawiam
Michoo

do góry

On Mon, 20 Feb 2012 14:51:06 +0100, Wojciech Jaczewski
<w...@o...pl> wrote:

>A. L. wrote:
>
>>>A czy przypadkiem używanie wątków (tam gdzie nie jest to na prawdę
>>>niezbędne) nie jest proszeniem się o kłopoty?
>>
>> Kolega zartuje, prawda?..
>
>Nie.
>Lubisz odsyłanie do książek... W kwestii wątków zgadzam się z "The Art of
>Unix programming".

Przepraszam, ale religia mnie nie interesuje.

A.L.

do góry

On Feb 20, 2:06 pm, Wojciech Jaczewski <w...@o...pl> wrote:
> Michoo wrote:
> > W dniu 20.02.2012 11:12, Wojciech Jaczewski pisze:
> >> A. L.  wrote:
>
> >>> [...] "ale ja bez watkow". Na pytanie "dlaczego" padaja rozne
> >>> [odpowiedzi. ...] "to jest sposob na klopoty"
>
> >> A czy przypadkiem używanie wątków (tam gdzie nie jest to na prawdę
> >> niezbędne) nie jest proszeniem się o kłopoty?
> > Abstrahując od niedouczonych programistów, którzy sobie z wątkami nie
> > radzą (niestety bardzo częste) to jakie kłopoty są możliwe?
>
> Jeśliby sobie wypisać wszystkie możliwe stany, w jakich może znaleźć się
> program wielowątkowy a w jakich jednowątkowy, to w wielowątkowym będzie ich
> znacznie więcej. Z tego w część z nich program będzie wchodził niezwykle
> rzadko (np. tylko przy obciążonym na 100% systemie) - co znacznie utrudni
> wychwycenie niektórych błędów.
>
> > Imo wątki nie dość, że zazwyczaj upraszczają zapis
>
> Kosztem dłuższego analizowania/testowania, czy gdzieś nie ma wyścigu.
>
> > (bo zazwyczaj
> > wymuszają model oparty o message passing) to jeszcze pozwalają na
> > łatwiejsze zmiany.
>
> Wolę message passing na procesach.
> Częściowo wynika to z tego, co dotychczas robiłem, a POSIX-owe API ma bardzo
> poważne - jak dla mnie - wady:
> - pthread_cond_timedwait operuje na czasie systemowym a nie monotonicznym

A do czego byś chciał używać tej funkcji, że ci to robi różnicę?

> - nie mam możliwości nastawić czekania (select/poll) na pierwsze ze zdarzeń:
> cond (lub semafor), otrzymanie danych na socket-cie.

Można to łatwo zrobić tworząc osobne wątki, które czekają na zdarzenie
i generują komunikat czy warunek, na który czeka "główny" wątek.

do góry

On Mon, 20 Feb 2012 14:51:06 +0100, Wojciech Jaczewski
<w...@o...pl> wrote:

>A. L. wrote:
>
>>>A czy przypadkiem używanie wątków (tam gdzie nie jest to na prawdę
>>>niezbędne) nie jest proszeniem się o kłopoty?
>>
>> Kolega zartuje, prawda?..
>
>Nie.
>Lubisz odsyłanie do książek... W kwestii wątków zgadzam się z "The Art of
>Unix programming". Zacząłem miec takie samo zdanie jak autorzy jeszcze zanim
>na tę książkę trafiłem.

Zajrzalem do tej ksizaki. Z dziejszego punktu widzenai to stek
nonsensow. To mniej wiecej tak jakby krytykowac, pardon, waterklozety,
mowiac ze slawojka jest znacznie bajedzie przyjazna srodowisku.

Dotyczy to Unixa, i owszem, gdzie procesy sa "lightweight" i nei ma
dobrego wsparcia dla watkow a jest dobre dla procesow. Gdzie sa
dowkonale mechanizmu komunikacji meidzy procesami, a watki dostepne sa
tylko w postaci dosyc kiepskiej biblioteki bez wsparcia jezykowego.
Ale nei wszystko jest Unix, i nie wszystko da sie latwo zdekomponowac
na procesy czy w ogole ma sens dekomponowac na procesy.

A.L.

do góry

On Mon, 20 Feb 2012 14:51:06 +0100, Wojciech Jaczewski
<w...@o...pl> wrote:

>A. L. wrote:
>
>>>A czy przypadkiem używanie wątków (tam gdzie nie jest to na prawdę
>>>niezbędne) nie jest proszeniem się o kłopoty?
>>
>> Kolega zartuje, prawda?..
>
>Nie.
>Lubisz odsyłanie do książek... W kwestii wątków zgadzam się z "The Art of
>Unix programming". Zacząłem miec takie samo zdanie jak autorzy jeszcze zanim
>na tę książkę trafiłem.

Poza tym jeszcze... Argument "to musi byc prawda bo jest napisane w
ksiazce" jest takim sobie argumentem w dyskusji

A.L.

do góry

W dniu 2012-02-19 22:26, Andrzej Jarzabek pisze:
> On 19/02/2012 21:14, A.L. wrote:
>> On Sun, 19 Feb 2012 19:18:08 +0100, szyk<s...@o...pl> wrote:
>>
>> Natomiast zeby nei wiem co pisac o "pair programming" i podobnych
>> rzeczach - koszt projektu jest sprawa najwazniejsza. Albowiem jak sie
>> sklada papiery w przetargu, to tzreba napisac ile projekt bedzie
>> kosztowal. Jak zorganizujemy go tak ze przy jednym komputerze bedzie
>> siedzialo dwoch facetow, to albo: a) koszt projektu wzrosnie
>> dwukrotnie, albo b) kazdy z facetow zadowoli sie polowa pensji. W tym
>
> Albo c) dwóch facetów zrobi to samo zadanie 2 razy szybciej niż 1 facet.

Nie do końca.

Jeden statek wiezie chiński badziew do europy 3 miesiące.
Ile zajmie transport badziewia 5 statkami.

;)

Programiści akurat doskonale wiedzą, że zysk ze zrównoleglenia
rzadko jest liniowy;-)

pzdr
bartekltg

do góry