On Sun, 19 May 2013 05:05:06 +0100, Andrzej Jarzabek
<a...@g...com> wrote:

>On 18/05/2013 02:34, A.L. wrote:
>> On Fri, 17 May 2013 07:33:00 +0100, Andrzej Jarzabek
>>>
>>> Może nie najszczęśliwiej dobrane słowo. Chodzi o to, że to to samo, co
>>> mutex i condition variable. Główny problem z użyciem tych konstruktów
>>> jest poprawny projekt, a w tym temacie synchronized/notify nie pomaga.
>>
>> Niestety, nie rozumiem.
>> Mozna prosic o szczegoly?...
>
>Po pierwsze, fakt istnienia w Javie synchronized i notify nie chroni
>przed problemami z wątkami.

Fakt. Tzreba umiec uzywac je w sposob wlasciwy

>I tak trzeba wiedzieć, które obiekty są
>dostępne z wielu wątków i trzeba sobie zaprojektować co ma być
>synchronized, w jaki sposób wątki się powiadamiają i tak dalej.
>

To tzreba zawsze wiedziec, niezaleznie ud uzytych narzedzi

>Ponadto - co prawda użycie synchronized i notify eliminuje część
>możliwych kombinacji z mutexami i condition variables (ale nadal beez
>gwarancji, że takie nie wystąpią, bo jawne mutexy też przecież w Jaie
>są), to wiedząc jak działają, ten sam efekt można w innych językach
>łatwo (przynajmniej w C++ łatwo) uzyskać przy pomocy mutex i condition
>variable.

Stwierdzenie jest trywialne. Java implementuje koncepcje "monitora"
wprowadzona pzrez Hoare i Brinch Hansena. Jest to konstrukcje wyzszego
poziomu niz "gole" mutexy. Oczywiscie, mozna zaimplementowac monitor
poslugujac sie wylacznie semaforami (co jest standardowym cwiczeniem
studenckim) ale to ma taka sama sile jak stwierdzenie ze "obiekty
takie jak w C++ sa niepotzrebne bo mozna je latwo zaimplementowac w C
poslugujac sie pointerami i makroprocesorem". Owszem, mozna. Ale
obiektowo programuje sie latwiej majac jezyk wspierajacy obiekty;
podobnie wielowatkowo programujesie latwiej majac jezyk wspierajacy
konstrukcje wyzszego poziomu niz mutex.

W Javie wystepuja mutexy, bo nei wszystkie problemy wzajemnego
wykluczania dadza sie zaimplementowac poslugujac sie "synchronized"
(albo byloby to bardzo nieczytelne). Do takich problemow nalezy na
przykald "wzajemne wykluczanie na grafie".

>Szczegółowo mam opisać jakbym taki odpowiednik zaimplementował
>w C++, czy nie ma takiej potrzeby?
>

Nie, nie ma potrzeby uczyc mnie programowania wielowatkowego. Uczylem
tego 15 lat

>Z tego co przeczytałem zresztą, to wygląda jakby C# oferował tę samą
>funkcjonalność przez klasę Monitor, polecenie lock i anotację
>[MethodImpl(MethodImplOptions.Synchronized)]. Mimo to OP przy wymaganiu
>o łatwej obsłudzę wątków wymienia swoje problemy z C# właśnie.

Owszem, C# oferuje bardzo podobny model monitora jak Java

Co nie znaczy ze monitor jest konstrukcja idealna... Sam Hoare wycofal
sie z tego konceptu proponujac w zamian CSP (Communicating Sequential
Processes)

A.L.

P.S. Jezeli ktos chce spojrzec glebiej na model wielowatkowosci w
javie, polacam nastepujaca prezentacje

http://www.cs.kent.ac.uk/projects/ofa/jcsp/csp-java-
model-6up.pdf

do góry

On 19/05/2013 17:20, A.L. wrote:
> On Sun, 19 May 2013 05:05:06 +0100, Andrzej Jarzabek
> <a...@g...com> wrote:
>
>> Po pierwsze, fakt istnienia w Javie synchronized i notify nie chroni
>> przed problemami z wątkami.
>
> Fakt. Tzreba umiec uzywac je w sposob wlasciwy

No więc jak już się umie, to to samo, równie łatwo, można zrobić na
mutexach itd. W innych językach, nie w Javie naturalnie, bo Java jest
takim topornym językiem.

>> I tak trzeba wiedzieć, które obiekty są
>> dostępne z wielu wątków i trzeba sobie zaprojektować co ma być
>> synchronized, w jaki sposób wątki się powiadamiają i tak dalej.
>
> To tzreba zawsze wiedziec, niezaleznie ud uzytych narzedzi

No chyba że się używa rozwiązan bez niejawnego dzielenia i jawnego
lockowania.

> Stwierdzenie jest trywialne. Java implementuje koncepcje "monitora"
> wprowadzona pzrez Hoare i Brinch Hansena. Jest to konstrukcje wyzszego
> poziomu niz "gole" mutexy. Oczywiscie, mozna zaimplementowac monitor
> poslugujac sie wylacznie semaforami (co jest standardowym cwiczeniem
> studenckim) ale to ma taka sama sile jak stwierdzenie ze "obiekty
> takie jak w C++ sa niepotzrebne bo mozna je latwo zaimplementowac w C
> poslugujac sie pointerami i makroprocesorem". Owszem, mozna. Ale
> obiektowo programuje sie latwiej majac jezyk wspierajacy obiekty;
> podobnie wielowatkowo programujesie latwiej majac jezyk wspierajacy
> konstrukcje wyzszego poziomu niz mutex.

W ogólności zgodziłbym się z tym zdaniem, ale akurat niekoniecznie w
odniesieniu do monitora. Znaczy, zależy oczywiście w od konkretneo
języka, ale dla wielu języków i wielu zagadnień jest tak, że
implementowanie czegoś w bibliotece funkcjonuje na tyle dobrze, że
wsparcie w języku w praktyce wcale niczego nie ułatwia.

do góry

On Sun, 19 May 2013 22:58:36 +0100, Andrzej Jarzabek
<a...@g...com> wrote:

>
>W ogólności zgodziłbym się z tym zdaniem, ale akurat niekoniecznie w
>odniesieniu do monitora. Znaczy, zależy oczywiście w od konkretneo
>języka, ale dla wielu języków i wielu zagadnień jest tak, że
>implementowanie czegoś w bibliotece funkcjonuje na tyle dobrze, że
>wsparcie w języku w praktyce wcale niczego nie ułatwia.

Rownie dobrze mozna twierdzic ze jezyki wysokiego poziomu nie sa
potzrebne, bo pzreciez mozna wszystko napisac w asemblerze.

Problem z wielowatkowoacia polega na tym ze mutexy i semafory sa
konstrukcjami bardzo niskiego poziomu. Cos jak "asembler
wspolbieznosci". Poniewaz systemow wielowatkowych nie da sie
efektywnie testowac, tzreba miec narzedzia umozliwiajace taka lub
owaka formalna weryfikacje programow. A to moze sie odbywac tylko
wtedy gdy program napisany jest przy pomocy przy pomocy konstrukcji
wyzszego poziomu niz "mutex"

A.L.

do góry

W dniu 2013-05-18 22:13, Kviat pisze:
> W dniu 2013-05-16 10:38, wloochacz pisze:
>> W dniu 2013-05-16 10:14, boryspower pisze:
>>> Hmm... Delphi wygląda/zapowiada się interesująco... tylko jedną z
>>> rzeczy o których zapomniałem wspomnieć jest, że przydałaby się
>>> technologia nie wymagająca dużych nakładów finansowych... takie Delphi
>>> to jednak 4200 EURO...
>> http://www.embarcadero.com/products/delphi/starter
>> Cena to 199 EUR z licencją komercyjną.
>
> 4. Prosta obsługa baz danych (minimum MySQL i jakieś bazy lokalne a'la
> SQLite)
>
> Delphi Starter Edition is a great way to get started building
> high-performance applications for Windows without database connectivity.
>
> Czy to ja czegoś nie zrozumiałem?
Zrozumiałeś, ale nie wszystko tam napisali :)

Starter Edition ma wyciętą obsługę baz danych i nie ma standardowych
komponentów takich jak DBGO (opartych ADO) czy dbExpress.
Ale posiada pełne wsparcie dla TDataSet (i innych "niskich" klas
obsługujących bazy danych w Delphi) i nic nie stoi na przeszkodzie, aby
zainstalować i używać komponentów trzecich. Mogą być komercyjne czy
OpenSource (np. ZEOS, UIB, FreeDAC, itd.), a tu oferta jest więcej niż
wystarczająca...


--
wloochacz

do góry

W dniu 2013-05-20 13:03, wloochacz pisze:
>>> http://www.embarcadero.com/products/delphi/starter
>>> Cena to 199 EUR z licencją komercyjną.
>>
>> 4. Prosta obsługa baz danych (minimum MySQL i jakieś bazy lokalne a'la
>> SQLite)
>>
>> Delphi Starter Edition is a great way to get started building
>> high-performance applications for Windows without database connectivity.
>>
>> Czy to ja czegoś nie zrozumiałem?
> Zrozumiałeś, ale nie wszystko tam napisali :)
>
> Starter Edition ma wyciętą obsługę baz danych i nie ma standardowych
> komponentów takich jak DBGO (opartych ADO) czy dbExpress.

Tak, to wiem. Ale...

> Ale posiada pełne wsparcie dla TDataSet (i innych "niskich" klas
> obsługujących bazy danych w Delphi) i nic nie stoi na przeszkodzie, aby
> zainstalować i używać komponentów trzecich. Mogą być komercyjne czy
> OpenSource (np. ZEOS, UIB, FreeDAC, itd.), a tu oferta jest więcej niż
> wystarczająca...

...bardziej mi chodziło o wzmiankowaną "prostotę" obsługi. Zależy co
autor miał na myśli.

O ile FreeDAC sam z powodzeniem używam do MSSQL, to do obsługi MySQL
wymaga dodatkowo biblioteki libmysql.dll (o ile się orientuję ZEOSy
również), a to już wymaga zakupu licencji od MySQL do używania w celach
komercyjnych lub dystrybucji swojego programu na licencji GPL (i nie
chcę zaczynać kolejnego flame na ten temat :))

Zresztą, przy normalnej wersji Delphi sytuacja jest podobna.

Co do komponentów komercyjnych, np.
http://www.microolap.com/products/connectivity/mysql
dac/order/
gdzie biblioteka libmysql.dll potrzebna nie jest, to wydatek dodatkowy $400.

Jak dla mnie taki komplet spełnia warunek prostoty i jest akceptowalny
cenowo. Ale czy to dla autora wątku jest "prosta obsługa baz danych"
tego nie wiem - stąd moja dygresja.

Pozdrawiam
Piotr

do góry

Dnia Mon, 20 May 2013 18:46:28 +0200, Kviat napisał(a):

> Co do komponentów komercyjnych, np.
> http://www.microolap.com/products/connectivity/mysql
dac/order/
> gdzie biblioteka libmysql.dll potrzebna nie jest, to wydatek dodatkowy $400.
>
> Jak dla mnie taki komplet spełnia warunek prostoty i jest akceptowalny
> cenowo. Ale czy to dla autora wątku jest "prosta obsługa baz danych"
> tego nie wiem - stąd moja dygresja.

A tylko MySQL kandyduje do miana bycia baza danych?

--
pozdro
R.e.m.e.K

do góry

On 2013-05-20, R.e.m.e.K <g...@d...null> wrote:
> Dnia Mon, 20 May 2013 18:46:28 +0200, Kviat napisał(a):
>
>> Co do komponentów komercyjnych, np.
>> http://www.microolap.com/products/connectivity/mysql
dac/order/
>> gdzie biblioteka libmysql.dll potrzebna nie jest, to wydatek dodatkowy $400.
>>
>> Jak dla mnie taki komplet spełnia warunek prostoty i jest akceptowalny
>> cenowo. Ale czy to dla autora wątku jest "prosta obsługa baz danych"
>> tego nie wiem - stąd moja dygresja.
>
> A tylko MySQL kandyduje do miana bycia baza danych?

*Kandyduje* tylko MySQL. Pozostałe produkty wokół nie muszą ledwie
kandydować :>

BP,NMSP.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu 2013-05-20 18:57, R.e.m.e.K pisze:
> Dnia Mon, 20 May 2013 18:46:28 +0200, Kviat napisał(a):
>
>> Co do komponentów komercyjnych, np.
>> http://www.microolap.com/products/connectivity/mysql
dac/order/
>> gdzie biblioteka libmysql.dll potrzebna nie jest, to wydatek dodatkowy $400.
>>
>> Jak dla mnie taki komplet spełnia warunek prostoty i jest akceptowalny
>> cenowo. Ale czy to dla autora wątku jest "prosta obsługa baz danych"
>> tego nie wiem - stąd moja dygresja.
>
> A tylko MySQL kandyduje do miana bycia baza danych?

Nie. Ale zacytuję ponownie":

"4. Prosta obsługa baz danych (minimum MySQL i jakieś bazy lokalne a'la
SQLite)"

Hmmm... ja te"minimum" zrozumiałem jako warunek konieczny, a inne bazy
jako bonus. Czyli, że obsługuje co najmniej MySQL.

Pozdrawiam
Piotr

do góry

Dnia Mon, 20 May 2013 19:14:12 +0200, Kviat napisał(a):

>> A tylko MySQL kandyduje do miana bycia baza danych?
>
> Nie. Ale zacytuję ponownie":
>
> "4. Prosta obsługa baz danych (minimum MySQL i jakieś bazy lokalne a'la
> SQLite)"
>
> Hmmm... ja te"minimum" zrozumiałem jako warunek konieczny, a inne bazy
> jako bonus. Czyli, że obsługuje co najmniej MySQL.

Imho warunek spelnia tez np. Firebird, kontrolki dostepowe sa za free. Do
tego ma wersje embedded, co jest duzym plusem. No i jest prawdziwym serwerem
SQL ;-)
Poza tym nie sadzisz, ze zarzucanie Delphi iz nie ma w pakiecie komercyjnej
biblioteki do jednej z dziesiatek baz jest strzalem kula w plot?
btw Delphi w wersji Enterprise za duuuzo zielonych tez chyba wymaga
libmysql.dll do dzialania. Mnie to specjalnie nie dziwi i nie martwi.

--
pozdro
R.e.m.e.K

do góry

On 2013-05-20, R.e.m.e.K <g...@d...null> wrote:
> Dnia Mon, 20 May 2013 19:14:12 +0200, Kviat napisał(a):
>
>>> A tylko MySQL kandyduje do miana bycia baza danych?
>>
>> Nie. Ale zacytuję ponownie":
>>
>> "4. Prosta obsługa baz danych (minimum MySQL i jakieś bazy lokalne a'la
>> SQLite)"
>>
>> Hmmm... ja te"minimum" zrozumiałem jako warunek konieczny, a inne bazy
>> jako bonus. Czyli, że obsługuje co najmniej MySQL.
>
> Imho warunek spelnia tez np. Firebird, kontrolki dostepowe sa za free. Do
> tego ma wersje embedded, co jest duzym plusem. No i jest prawdziwym serwerem
> SQL ;-)

Tylko że zarządzanie nim jest bardzo uciążliwe. Za użycie Firebirda
w nowo tworzonych aplikacjach powinno się komisyjnie ucinać ręce.

--
Secunia non olet.
Stanislaw Klekot

do góry