On 20/02/2012 18:29, Edek Pienkowski wrote:
> (nie da się popsuć). Jeszcze jedna czy dwie wersje gcc i
> transactional memory będzie dostarczane z kompilatorem, a za
> jakiś czas będzie standartem faktycznym i skończy się to voodoo.

łudzisz się. Po pierwsze, pamięć transakcyjna musi mieć wsparcie w
sprzęcie, a to dopiero jest na etapie eksperymentów. Po drugie, prawo
Amdahla pozostanie i trzeba będzie się gimnastykować nad skalowalnością
programów niezależnie od tego jak będą wyglądały mechanizmy synchronizacji.


B.

do góry

On 20/02/2012 19:26, Bronek Kozicki wrote:
> On 20/02/2012 18:29, Edek Pienkowski wrote:
>> (nie da się popsuć). Jeszcze jedna czy dwie wersje gcc i
>> transactional memory będzie dostarczane z kompilatorem, a za
>> jakiś czas będzie standartem faktycznym i skończy się to voodoo.
>
> łudzisz się. Po pierwsze, pamięć transakcyjna musi mieć wsparcie w
> sprzęcie,

zanim ktoś mnie weźmie za słowo, dodam: bo inaczej bez tego jest zbyt
wolna, aby była pożyteczna na większą skalę.


B.

do góry

W dniu 20.02.2012 19:29, Edek Pienkowski pisze:
> Ale zgadzam się, że wielu programistów tego nie ogarnia,
> co jest jedną z dwóch głównych motywacji transactional memory
> (nie da się popsuć). Jeszcze jedna czy dwie wersje gcc i
> transactional memory będzie dostarczane z kompilatorem, a za
> jakiś czas będzie standartem faktycznym i skończy się to voodoo.
Pamięć transakcyjna oparta o biglock ma rozwiązać problem?

--
Pozdrawiam
Michoo

do góry

Dnia Mon, 20 Feb 2012 20:31:46 +0100, Michoo napisal:

> W dniu 20.02.2012 19:29, Edek Pienkowski pisze:
>> Ale zgadzam się, że wielu programistów tego nie ogarnia,
>> co jest jedną z dwóch głównych motywacji transactional memory (nie da
>> się popsuć). Jeszcze jedna czy dwie wersje gcc i transactional memory
>> będzie dostarczane z kompilatorem, a za jakiś czas będzie standartem
>> faktycznym i skończy się to voodoo.
> Pamięć transakcyjna oparta o biglock ma rozwiązać problem?

Nie rozumiem. Dlaczego oparta o biglock? Co to ma do kwestii
"programowanie bez locków nie wywoła deadlocków"?

Edek

do góry

Dnia Mon, 20 Feb 2012 19:31:11 +0000, Bronek Kozicki napisal:

> On 20/02/2012 19:26, Bronek Kozicki wrote:
>> On 20/02/2012 18:29, Edek Pienkowski wrote:
>>> (nie da się popsuć). Jeszcze jedna czy dwie wersje gcc i transactional
>>> memory będzie dostarczane z kompilatorem, a za jakiś czas będzie
>>> standartem faktycznym i skończy się to voodoo.
>>
>> łudzisz się. Po pierwsze, pamięć transakcyjna musi mieć wsparcie w
>> sprzęcie,
>
> zanim ktoś mnie weźmie za słowo, dodam: bo inaczej bez tego jest zbyt
> wolna, aby była pożyteczna na większą skalę.

Ja pisalem o "nie da się zepsuć", a nie o tym, o czym pisze większość,
czyli demonie szybkości. Wydajność tego typu jest potrzebna może w 1%
zastosowań.

Edek

do góry

Dnia Mon, 20 Feb 2012 19:55:36 +0000, Edek Pienkowski napisal:

> Dnia Mon, 20 Feb 2012 20:31:46 +0100, Michoo napisal:
>
>> W dniu 20.02.2012 19:29, Edek Pienkowski pisze:
>>> Ale zgadzam się, że wielu programistów tego nie ogarnia,
>>> co jest jedną z dwóch głównych motywacji transactional memory (nie da
>>> się popsuć). Jeszcze jedna czy dwie wersje gcc i transactional memory
>>> będzie dostarczane z kompilatorem, a za jakiś czas będzie standartem
>>> faktycznym i skończy się to voodoo.
>> Pamięć transakcyjna oparta o biglock ma rozwiązać problem?
>
> Nie rozumiem. Dlaczego oparta o biglock? Co to ma do kwestii
> "programowanie bez locków nie wywoła deadlocków"?


Dodaję, że przypuszczam, że pomyliłeś implementację z semantyką:

The transactional memory system to be implemented in GCC provides single
lock atomicity semantics. That is, a program behaves as if a single
global lock guards each transaction.

Kluczowe jest "as if".

Pozdrawiam
Edek

do góry

A. L. wrote:

> Poza tym zadziwie mnei pakowanie watkow do kategorii "moda". Ciekawe
> jak Kolega zrobi pod Windows, w Javie, program ktory bedzie robil
> dlugie obliczenia, a uzytkownik bedzie chcial mniec wglad w stan tych
> obliczen bez przerywania procesu obliczania. Rozumiem ze bedzie jedna
> wielka petla ktora co milisekunde bedzie sprawdzala stan klawiatury i
> co milisekunde wysylala na ekran?

Gałąź wątku zaczęła się od komentarza dotyczącego programisty C++. Inaczej
się robi w Javie (nie mam w niej większego doświadczenia) a inaczej w C++.

W C++ długotrwałe obliczenia wolałbym wyrzucić do osobnego procesu - bo
proces w przeciwieństwie do wątku, zawsze daje się zatrzymać/ubić - gdyby
użytkownik stwierdził że jednak mu to obliczenie niepotrzebne.

do góry

Andrzej Jarzabek wrote:

>> 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ę?

Włącza się jakieś urządzenie, które mogło być ileś dni wyłączone, więc ma
zegar rozsynchronizowany o kilka minut. Synchronizacja nastąpi wtedy, gdy
będzie łączność z internetem, a ta może być od razu, a może za pół godziny.

Nie mogę w takim przypadku używać pthread_cond_timedwait, bo zamiast
poczekać planowane np. 5 sekund, raz poczeka mi 0 sekund a raz 5 minut.

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

I w ten sposób zwiększyć komplikację programu, bo pojawia się więcej
równoległych wątków niż byłoby w wersji z potokami/gniazdami.

do góry

Michoo wrote:

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

A czy masz jakieś narzędzie, które automatycznie zweryfikuje, że
rzeczywiście cały kontekst jest enkapsulowany? W przypadku procesów: jeśli
nie używają pamięci dzielonej - jest oczywiste, że cały kontekst przechodzi
przez potoki/gniazda/itp. Jeśli jest pamięć dzielona, jest gwarancja że
jeden proces może namieszać drugiemu tylko w tej pamiędzi dzielonej, ale nie
w pozostałych blokach.
[Podejrzewam że istnieją języki, w których da się taką weryfikację zrobić; w
tej chwili chodzi mi o C/C++].

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

Pewnie w niektórych przypadkach mogą być dobre.
Ja po prostu widziałem (a i sam tak robiłem dopóki się tego nie oduczyłem)
bardzo wiele programów, które dało się zrobić w jednym wątku na select/poll,
a były robione na wielu wątkach, co skutkowało wielokrotnie dłuższym czasem
ich testowania i likwidowania co bardziej uciążliwych błędów.
Prawie każdy wie co to jest wątek i do czego służy, natomiast znacznie
mniejszej liczbie ludzi chce się zagłębić w to, jak działa system
operacyjny, w którym tworzone przez nich programy będą uruchamiane i jakie
przydatne rzeczy ten system oferuje.
Jeśli ktoś zna alternatywy i wybierze wątki - OK, ale często wybieranie
wątków wynika z nieznajomości tych alternatyw.

do góry

On Monday, February 20, 2012 6:27:31 PM UTC, A. L. wrote:

> Poza tym zadziwie mnei pakowanie watkow do kategorii "moda". Ciekawe
> jak Kolega zrobi pod Windows, w Javie, program ktory bedzie robil
> dlugie obliczenia, a uzytkownik bedzie chcial mniec wglad w stan tych
> obliczen bez przerywania procesu obliczania. Rozumiem ze bedzie jedna
> wielka petla ktora co milisekunde bedzie sprawdzala stan klawiatury i
> co milisekunde wysylala na ekran?

Nawet taki pozornie prosty problem jak "piszemy addin do Excela ktory musi stworzyc
swoje wlasne okienko dialogowe, ktore umozliwia kopiowanie danych pomiedzy soba a
arkuszem Excela" konczy sie na uzyciu watkow.

RW

do góry