[OT] Wspanialosci JIT i ogolnie
arturbac
Od czasu do czasu ktos pise jakie to JIT i w og�le bytecody sa fajne i
generalnei tak samo wydajne.
A ja systematycznie co jakis czas zmuszony w jednej apliakcji do
uzywania tego badziewia dosteje zimny prszynic, a to GC i MT sie nie
lubia, to GC wykladniczo spowlania wzraz ze wzrostem zuycia ram a to
najnowszy badziew ktory przyszedl "chyba" razem z jakims service pack.
Ni z tad niz ow�d program zacz�� (potwierdozne na 2 maszynach z
aktualnymi updatami) zrzeraz 50% czasu w/g AmdCodeAnalist
na:
55% mscorworks
18% hal.dll
ntdll 8.5%
reszta to moj kod i inna badzwiewa
w tym mscorworks spedza:
CompareAssemblyIdentity 65%
IEE 9%
CreateAssemblyNameObject 6%
GetAssemblyIdentityFromFile 4%
....
CertCreateAuthenticodeLicense 1.5%
No to mam dola bo nic nie laduje dynamicznie, a wszelkie assembly sa
budowane razem w tym samym projekcie.
Ma ktos pomysl jak wysledzi jakei assembly jest w kolko ladowane i
zwalniane i przedewszystkim po co ?
BTW: ... wole C++ przynajmiej absolutnie wszystko jest deterministyczne
w zakresie tego co napisze.
arturbac
> [OT] Ku przestrodze ... uzywania tego badziewia
>
> Od czasu do czasu ktos pise jakie to JIT i w og�le bytecody sa fajne i
> generalnei tak samo wydajne.
> A ja systematycznie co jakis czas zmuszony w jednej apliakcji do
> uzywania tego badziewia dosteje zimny prszynic, a to GC i MT sie nie
> lubia, to GC wykladniczo spowlania wzraz ze wzrostem zuycia ram a to
> najnowszy badziew ktory przyszedl "chyba" razem z jakims service pack.
>
> Ni z tad niz ow�d program zacz�� (potwierdozne na 2 maszynach z
> aktualnymi updatami) zrzeraz 50% czasu w/g AmdCodeAnalist
> na:
>
> 55% mscorworks
> 18% hal.dll
Aby bylo ciekawiej w hal.dll spedza 99% na QueryPerformanceCounter.
Wiktor Zychla
taki spos�b formu�owania problemu nie zach�ca do jakiekolwiek pomocy.
> Ni z tad niz ow�d program zacz�� (potwierdozne na 2 maszynach z aktualnymi
> updatami) zrzeraz 50% czasu w/g AmdCodeAnalist
tylko na dw�ch, czy na wszystkich?
> w tym mscorworks spedza:
> CompareAssemblyIdentity 65%
> IEE 9%
> CreateAssemblyNameObject 6%
> GetAssemblyIdentityFromFile 4%
> ....
> CertCreateAuthenticodeLicense 1.5%
>
> No to mam dola bo nic nie laduje dynamicznie, a wszelkie assembly sa
> budowane razem w tym samym projekcie.
napisz co� o tym co to jest za program. wystarczy �e to jaka� us�uga
sieciowa albo korzysta z serializacji xml i juďż˝ masz dynamicznie kreowane i
�adowane assembly, kt�re z jakiego� powodu kto� ci�gle wy�adowuje / zmienia.
projekt du�y / ma�y, hybrydowy, jak hostowany?
>
> Ma ktos pomysl jak wysledzi jakei assembly jest w kolko ladowane i
> zwalniane i przedewszystkim po co ?
mo�e Process Explorer?
poogl�da� czy tam si� tworz� jakie� w�tki i czy nie pr�buj� robi� jakich�
cud�w?
mo�e te� popodpinaj si� pod zdarzenia AppDomain i zobacz czy tam czego� nie
widaďż˝.
pozdrawiam
Wiktor Zychla
Sebastian Biały
> w/g AmdCodeAnalist
Zupe�nie na marginesie: jak oceniasz to narzedzie? Mam co prawda Intela,
ale dzia�a. Problem w tym, �e:
a) odpalenie tego samego programu N-krotnie na tych samych danych daje N
r�nych wynik�w (zblizonych, ale nijak maj�c si� do rozrzutu
statycznego, raczej do randomicznego).
b) klikanie po wynikach czasami zmienia warto�ci i przesortowuje
znacz�co wyniki (!).
c) Callstack jest mocno bezu�yteczny bez graf�w.
d) niekt�re templatey powoduj� zwis/gpf.
Sam nie wiem na ile jest to przydatne i wiarygodne.
arturbac
>> [OT] Ku przestrodze ... uzywania tego badziewia
>
> taki spos�b formu�owania problemu nie zach�ca do jakiekolwiek pomocy.
>
>> Ni z tad niz ow�d program zacz�� (potwierdozne na 2 maszynach z
>> aktualnymi updatami) zrzeraz 50% czasu w/g AmdCodeAnalist
>
> tylko na dw�ch, czy na wszystkich?
aktual nie wszystkich, odpale jescze na trzeciej.
>
>> w tym mscorworks spedza:
>> CompareAssemblyIdentity 65%
>> IEE 9%
>> CreateAssemblyNameObject 6%
>> GetAssemblyIdentityFromFile 4%
>> ....
>> CertCreateAuthenticodeLicense 1.5%
>>
>> No to mam dola bo nic nie laduje dynamicznie, a wszelkie assembly sa
>> budowane razem w tym samym projekcie.
>
> napisz co� o tym co to jest za program. wystarczy �e to jaka� us�uga
> sieciowa albo korzysta z serializacji xml i juďż˝ masz dynamicznie
> kreowane i �adowane assembly, kt�re z jakiego� powodu kto� ci�gle
> wy�adowuje / zmienia.
>
> projekt du�y / ma�y, hybrydowy, jak hostowany?
du�y/hybrydowy/rozproszony na wiele procesow.
>
>>
>> Ma ktos pomysl jak wysledzi jakei assembly jest w kolko ladowane i
>> zwalniane i przedewszystkim po co ?
>
> mo�e Process Explorer?
> poogl�da� czy tam si� tworz� jakie� w�tki i czy nie pr�buj� robi�
> jakich� cud�w?
>
> mo�e te� popodpinaj si� pod zdarzenia AppDomain i zobacz czy tam czego�
> nie widaďż˝.
Jasne dzieki, bede lukaďż˝ i na pewno nie odpuszcze.
arturbac
> arturbac wrote:
>> w/g AmdCodeAnalist
> Sam nie wiem na ile jest to przydatne i wiarygodne.
IMHO To sie nadaje tylko w zakresie probkowania co obciaza proces jako
taki w zanaczacym stopniu.
Generalnie ma problem z hybrydowym kodem choc potrafi poakzac kod jita.
W zakresie kodu natywnego jak dla mnie dziala spoko w zakresie tego
probkowania a nawet daje rade z netem slabo ale jakos zawsze.
Czesto jest tak ze widac skutek a nie przyczyne czyli widaďż˝ wielokrotnei
wo��nego zamiast realnie wo�ajacego.
Krzysiek
Wed�ug go�cia od Virtual Duba, "CodeAnalyst works fine on an Intel CPU,
as long as you use Time-Based Sampling (TBS). It will blue-screen the
machine if you use Event-Based Sampling (EBS) or Pipeline Simulation, or
at least it used to. Call graph profiling might not work either, but I
never use that anyway."
http://www.virtualdub.com/blog/pivot/entry.php?id=288#body
--
Pozdrawiam,
Krzysiek
Wiktor Zychla
jak coďż˝ znajdziesz, napisz, niech zostanie dla potomnych.
pozdrawiam
Wiktor Zychla
arturbac
> mo�e Process Explorer?
> poogl�da� czy tam si� tworz� jakie� w�tki i czy nie pr�buj� robi�
> jakich� cud�w?
A tak przy okazji WIN32/WIN64:
Mam sobie apliakcje CLR czy natwyna wsio ryba.
Patrze w TaskManager->Col->Threads (trzeba w opcjach w�aczyc)
i tych jest zawsze wiecej niz 1 glowny + ilosc utworzona przeze mnie.
O ile rozumie ze nad CLR nie panuje i GC sobie chodzi na swoim i to
generalnie czarna skrzynka .NET o tyle nie rozumie skad siďż˝ biorďż˝ te
dodatkowe watki w kodzie natywnym ?
arturbac
>> Jasne dzieki, bede lukaďż˝ i na pewno nie odpuszcze.
>
> jak coďż˝ znajdziesz, napisz, niech zostanie dla potomnych.
Nie omieszkam.
arturbac
Thread 4 ".NET System Events" zaiwania na poziomie 49% calosci czasu
procesu.
Ani nie wolam DoEvents ani nic z tych rzeczy a aplikacja jest consolowa
(proces rozproszonej generacji)
I co z tym badziwiem zrobic tj co moze to powodowac ?
arturbac
49,92% Thread ".NET SystemEvents" - 51559 ms - 0 calls
49,92% ThreadStart - 51559* ms - 0 calls -
System.Threading.ThreadHelper.ThreadStart()
49,92% Thread #2656688 - 51559 ms - 0 calls
49,92% mainCRTStartupStrArray - 51559* ms - 0 calls -
.mainCRTStartupStrArray(String [])
49,92% main - 51559* ms - 0 calls - .main(String [])
49,92% fn - 51559* ms - 0 calls - .fn(cmd_arguments_t) (from mm)
49,92% worker_mode - 51559* ms - 0 calls -
.worker_mode(cmd_arguments_t) (from mm)
49,92% Start - 51559* ms - 0 calls - mm.Worker.Start()
[...]
0,16% Thread #2686864 - 163 ms - 0 calls
0,05% Finalize - 56 ms - 27354 calls - System.Drawing.Pen.Finalize()
0,03% Finalize - 33 ms - 22591 calls - System.Drawing.Brush.Finalize()
0,03% System.Collections.Generic.DataNode.DataNode.Dispose... - 31 ms
- 20293 calls
[...]
arturbac
To duzo tlumaczy ale nic nie zmienia ani dla MTA ani STA
http://www.dotnet247.com/247reference/msgs/53/268529.aspx
spy pokazuje 0 komunikatow w watku a ten zapierdziela jak wsciekly, a
wymuszanie STA nic nie daje bo i tak ten watek powstaje.
A.
arturbac
Nawet ustawienie STA i objescie tego watku (MTA prawidlowe rozwiazanie
dla konsoli) nic nie zmienia w czasie dzialania nadal jest 2x
arturbac
Przygladajac sie smaplowaniu jednak chodzi o GC i torche
QueryPerformanceCounter i juz jestem kompletnie skolowany.
Module Name 64-bit Timer samples
mscorwks.dll 1 54.5
hal.dll 1 15.34
ntdll.dll 1 9.22
3 modules, Total: 381698 samples, 79.06% of total session samples
hal.dll
-------------------
CS:EIP Symbol + Offset 64-bit Timer samples
0xfffff80000810410 KeQueryPerformanceCounter 1 99.56
0xfffff80000810320 KeStallExecutionProcessor 1 0.25
2 functions, 21 instructions, Total: 73907 samples, 99.81% of samples in
the module, 15.31% of total session samples
mscorwks.dll
---------------------
CS:EIP Symbol + Offset 64-bit Timer
samples
0x6427f4f4830 Thread::StackWalkFramesEx 1 13.74
0x6427f525e3c EEJitManager::JitCodeToMethodInfo 1 6.77
0x6427f4f6040 EEJitManager::FindMethodCode 1 5.89
0x6427f4f9aa0 GcInfoDecoder::GcInfoDecoder 1 5.39
0x6427f4f6260 EECodeManager::GetGSCookieAddr 1 3.99
0x6427faccc40 DemandStackWalk::WalkFrame 1 3.99
0x6427f4ffb10 HashMap::LookupValue 1 3.77
0x6427f51a510 WKS::gc_heap::mark_object_simple1 1 2.13
0x6427f538d70 EEJitManager::GetFunctionEntry 1 2.09
0x6427fa07040 CrstBase::Enter 1 2.05
0x6427f537780 WKS::gc_heap::plan_phase 1 1.73
0x6427f5fe890 memset 1 1.66
0x6427f5fecc0 GetThread 1 1.47
0x6427f50a830 EECodeManager::GetAddrOfSecurityObject 1 1.35
0x6427f558a7c CrawlFrame::GetAssembly 1 1.23
0x6427f51f330 EECodeManager::QuickUnwindStackFrame 1 1.21
0x6427f7999d0 `string' 1 1.2
0x6427f5430d0 WKS::gc_heap::relocate_survivors_in_plug 1 0.92
0x6427f98c290 SecurityStackWalk::IsSpecialRunFrame 1 0.92
0x6427f51f0bc IJitManager::GetScanFlags 1 0.9
0x6427f53cf10 WKS::gc_heap::find_first_object 1 0.9
0x6427f5706a0 WKS::qsort1 1 0.87
22 functions, 2254 instructions, Total: 168851 samples, 64.17% of
samples in the module, 34.97% of total session samples
Wiktor Zychla
> dodatkowe watki w kodzie natywnym ?
gc ma bodaj 4 w�tki (?)
arturbac
>> generalnie czarna skrzynka .NET o tyle nie rozumie skad siďż˝ biorďż˝ te
>> dodatkowe watki w kodzie natywnym ?
>
> gc ma bodaj 4 w�tki (?)
jak obserwuje profilowanie to GC i finalizacja jest w 1 watku.
+1 dla MTAThread na pule komunikatow
GC z tego co czytalem w trybie serwerowym dla col gen 0 dziala
wielowatkowo "chyba w ramach watkow uzytkownika" ale dla gen 1 i 2 juz
robi stop the world i jedzie jednym kanalem calosc.
A.
nightwatch77
pewno wiele osób z listy widziało aplikacje konsolowe .Net które nie
zużywają 50% procka.
arturbac
> A mo�e problem jest w Twoim kodzie a szukasz go wsz�dzie indziej? Na
> pewno wiele os�b z listy widzia�o aplikacje konsolowe .Net kt�re nie
> zu�ywaj� 50% procka.
Masz racje nie wteirdze inaczej.
arturbac
Problem byl w moim kodzie ale to architektura .NET jest temu winna.
GC nie umie w okreslonych okolicznosciach prawidlowo zwalniac zasob�w
doprowadzajac do sytuacji w ktorej sprzatanie zajmuje 50% czasu.
Brak destruktorow sprawia ze prograzmowanie w .NET przypomina zabwe w
malloc/free jak w C w zakresie wszystkiego co ma interfejs IDisposable
to dokaldnie prehistoria w porownaniu do C++. Wystarczy jeden brak
Dispose lub using() {} o ktorym programista musi wszedzie pamietac i
zamiast sprzatniecia od razu wszystko trafia do GC i nawarstwia problem
podczas Finalize gdzie aby zwolnic zasob GC musi tworzyc drzewo wszytkie
obiektow i ich zaleznosci a to pwooduje zmulenei o 50%.
IMHO to archaizm w porownaniu do scoped_ptr czy shared_ptr w C++
notabene trudny do opanowania w obiektach wspoldzielonych gdzie nie
mozna w prosty sposob uzyc (using IDisposable ob = new )
arturbac
Chyba najlepiej to widac w przypadku C++ CLI gdzie odpowiednikiem
C#
IDisposable obj = new SomeType
...
obj.Dispose();
jest
IDisposable^ obj = gcnew SomeType();
...
delete obj;
Takie programowanie to archamizm i po coz jest ten GC po to by znowu
bawic sie w new/delete z reki ? Taki kod sie natychmaist msci,
programujac w C++ z gory analizuje czy uzyje scoped_ptr czy
shared_ptr(intruzive,nonintruzive) i nigdy nie mam takich problemow.
A.
nightwatch77
Łukasz 'Maly' Ostrowski
> Chyba najlepiej to widac w przypadku C++ CLI gdzie odpowiednikiem
> C#
> IDisposable obj = new SomeType
> ...
> obj.Dispose();
Nie Dispose, tylko using. A jak w "..." poleci exception?
--
Pozdrawiam,
�ukasz 'Maly' Ostrowski. http://l3v.pl/
ICQ: 148498663 GG: 2544385 AIM: malyzgora
GTalk: l3vi...@gmail.com ASTRA: L3viathan
Bronek Kozicki
> arturbac pisze:
>> nightwatch77 pisze:
>>> A mo�e problem jest w Twoim kodzie a szukasz go wsz�dzie indziej? Na
>>> pewno wiele os�b z listy widzia�o aplikacje konsolowe .Net kt�re nie
>>> zu�ywaj� 50% procka.
>>
>> Masz racje nie wteirdze inaczej.
>
> Problem byl w moim kodzie ale to architektura .NET jest temu winna.
> GC nie umie w okreslonych okolicznosciach prawidlowo zwalniac zasob�w
> doprowadzajac do sytuacji w ktorej sprzatanie zajmuje 50% czasu.
> Brak destruktorow sprawia ze prograzmowanie w .NET przypomina zabwe w
> malloc/free jak w C w zakresie wszystkiego co ma interfejs IDisposable
> to dokaldnie prehistoria w porownaniu do C++. Wystarczy jeden brak
to nie wina .NET - podobnie wygl�da GC na ka�dej platformie. Zauwa�
powszechno�� konstrukcji try ... finally w programach w Javie - z tego
samego powodu. To jest te� pow�d dlaczego C++0x nie ma pe�noprawnego GC
- nie by�o prostego sposobu �e zagwarantowa� wsp�prac� z RAII.
B.
Sebastian Nibisz
> to nie wina .NET - podobnie wygl�da GC na ka�dej platformie. Zauwa�
> powszechno�� konstrukcji try ... finally w programach w Javie - z tego
> samego powodu. To jest te� pow�d dlaczego C++0x nie ma pe�noprawnego GC -
> nie by�o prostego sposobu �e zagwarantowa� wsp�prac� z RAII.
A wiesz mo�e dlaczego, destruktory struktur nie s� wo�ane deterministycznie?
Struktury s� przecie� kopiowane przez warto��.
Pozdrawiam,
- Bastek -
Bronek Kozicki
o ile pami�tam, struktury nie maj� w og�le destruktor�w (destruktorem w
.NET jest IDisposable).
B.
Sebastian Nibisz
> o ile pami�tam, struktury nie maj� w og�le destruktor�w (destruktorem w
> .NET jest IDisposable).
Wiem, �e C# ma pomieszane destruktory z finalizatorami.
Pomijaj�c jednak ten fakt uwa�am, �e struktury m�g�by posiada� destruktor
wo�ane deterministycznie.
Pozdrawiam,
- Bastek -
arturbac
> On Sat, 19 Dec 2009 16:28:44 +0100, arturbac wrote:
>> Chyba najlepiej to widac w przypadku C++ CLI gdzie odpowiednikiem
>> C#
>> IDisposable obj = new SomeType
>> ...
>> obj.Dispose();
>
> Nie Dispose, tylko using. A jak w "..." poleci exception?
>
Specjalnie napisalem Dispose !
IMHO problemy mam w kodzie gdzie nie moge po prostu uzyc using(
IDisposable){} bo sa to obiekty wspoldzielone o dluzszym czasie zycia.
Zwykly SharedPtr dzialalby bardoz dobrze a w czesci przypadkow ScopedPtr.
arturbac
Ciekawostka :
CLI/C++
public value struct (class jak ktos woli) Foo : IDisposable
{
};
//ok podczas kompialcji.
public value struct (class jak ktos woli) Foo : IDisposable
{
~Foo() {} //IDisposable
!Foo() {} //Finalize
};
error C3417: 'Foo::~Foo(void)' : value types cannot contain user-defined
special member functions
error C3077: 'Foo::!Foo' : a finalizer can only be a member of a
reference type
IMHO IDisposable nie nadaje sie dla typow wartosiowych bo nei da sie
zwolnic zasobo poprzez destruktor ktorego nei mozna napisac ani
finalizer ktorego nie da sie wdrozyc dla typu nie referencyjnego pzoa
sterta zarzadzana.
Sebastian Kaliszewski
> �ukasz 'Maly' Ostrowski pisze:
>> On Sat, 19 Dec 2009 16:28:44 +0100, arturbac wrote:
>>> Chyba najlepiej to widac w przypadku C++ CLI gdzie odpowiednikiem
>>> C#
>>> IDisposable obj = new SomeType
>>> ...
>>> obj.Dispose();
>>
>> Nie Dispose, tylko using. A jak w "..." poleci exception?
>>
>
> Specjalnie napisalem Dispose !
>
> IMHO problemy mam w kodzie gdzie nie moge po prostu uzyc using(
> IDisposable){} bo sa to obiekty wspoldzielone o dluzszym czasie zycia.
To po co sďż˝ IDisposable?
> Zwykly SharedPtr dzialalby bardoz dobrze a w czesci przypadkow ScopedPtr.
Mo�e jest jak jest dlatego, �e my�lisz po Ceplusplusowemu?
pzdr
\SK
--
"Never underestimate the power of human stupidity" -- L. Lang
--
http://www.tajga.org -- (some photos from my travels)
Sebastian Kaliszewski
> On 19/12/2009 15:24, arturbac wrote:
>> arturbac pisze:
>>> nightwatch77 pisze:
>>>> A mo�e problem jest w Twoim kodzie a szukasz go wsz�dzie indziej? Na
>>>> pewno wiele os�b z listy widzia�o aplikacje konsolowe .Net kt�re nie
>>>> zu�ywaj� 50% procka.
>>>
>>> Masz racje nie wteirdze inaczej.
>>
>> Problem byl w moim kodzie ale to architektura .NET jest temu winna.
>> GC nie umie w okreslonych okolicznosciach prawidlowo zwalniac zasob�w
>> doprowadzajac do sytuacji w ktorej sprzatanie zajmuje 50% czasu.
>> Brak destruktorow sprawia ze prograzmowanie w .NET przypomina zabwe w
>> malloc/free jak w C w zakresie wszystkiego co ma interfejs IDisposable
>> to dokaldnie prehistoria w porownaniu do C++. Wystarczy jeden brak
>
> to nie wina .NET - podobnie wygl�da GC na ka�dej platformie.
Nie.
> Zauwaďż˝
> powszechno�� konstrukcji try ... finally w programach w Javie - z tego
> samego powodu.
Nie z tego samego. Wynika po prostu z braku nietrywialnych destruktor�w
i z faktu �e w Javie praktycznie ka�dy nietrywialny obiekt
(semantycznie) l�duje na stercie.
> To jest te� pow�d dlaczego C++0x nie ma pe�noprawnego GC
> - nie by�o prostego sposobu �e zagwarantowa� wsp�prac� z RAII.
Aleďż˝ jedno drugiemu tak bardzo nie przeszkadza. Patrz: D.
Akurat troch� �ledzi�em kwesti� GC w C++. U�ycie domy�lnego GC oznacza
z�amanie kompatybilno�ci wstecz i to kompatybilno�ci z rzeczami kt�rych
si� nie bardzo dawa�o weryfikowa� ani statycznie ani dynamicznie. GC w
przysz�ym C++ musi by� wi�c opcjonalny, jawnie w��czany przez
programist�. W dodatku platforma nie musi go w og�le implementowa� (co
juďż˝ jest gorsze)
Piotr Wyderski
> to nie wina .NET - podobnie wygl�da GC na ka�dej platformie.
"U mnie dzia�a". Obecnym tu kolegom Sebastianom, kt�rzy
r�wnie� napisali swoje GC, te� dzia�a. A r�ni� si� nasze podej�cia
chyba wszyskim -- np. m�j od�miecacz ma ma�e narzuty, lecz jest
intruzywny, �mieciuch i ten drugi nie s� intruzywne.
> Zauwa� powszechno�� konstrukcji try ... finally w programach w Javie
Ja nie mam finalizator�w, tylko normalne destruktory.
> - z tego samego powodu. To jest te� pow�d dlaczego C++0x nie
> ma pe�noprawnego GC
Tam w og�le nie ma wsparcia dla GC. Jest jedynie niewielki uk�on
w stron� od�miecacza wg koncepcji Boehma, kt�ra to ma moim
zdaniem wi�cej wad niz zalet.
> - nie by�o prostego sposobu �e zagwarantowa� wsp�prac� z RAII.
Jakiego rodzaju wsp�prac�? Np. mi do pe�ni szcz�cia wystarczy�oby
wsparcie pozwalajace rozpoznac spos�b konstrukcji obiektu. Taki
overloading:
class C {
static C(...) { wo�any przy konstrukcji statycznej }
auto C(...) { wo�any przy konstrukcji automatycznej }
C(...) { wo�any przy new oraz domy�lnie, je�li innych przeci��e� nie
ma }
// Podobnie z destruktorami
static ~C(); // itd.
};
Korzystaj�c z delegacji konstruktor�w z C++0x mo�na wtedy redukowa�
je do pojedynczej/dw�ch implementacji.
Pozdrawiam
Piotr Wyderski
Bronek Kozicki
>> Zauwa� powszechno�� konstrukcji try ... finally w programach w Javie -
>> z tego samego powodu.
>
> Nie z tego samego. Wynika po prostu z braku nietrywialnych destruktor�w
> i z faktu �e w Javie praktycznie ka�dy nietrywialny obiekt
> (semantycznie) l�duje na stercie.
no w�a�nie deterministyczne destruktory s� semantycznie niezgodne z GC.
>> To jest te� pow�d dlaczego C++0x nie ma pe�noprawnego GC - nie by�o
>> prostego sposobu �e zagwarantowa� wsp�prac� z RAII.
>
> Aleďż˝ jedno drugiemu tak bardzo nie przeszkadza. Patrz: D.
to nie jest C++ . Powtarzam - nie ma prostego sposobu �eby w C++
opanowa� konflikt pomi�dzy istniejacymi deterministycznymi destruktorami
a GC.
B.
Sebastian Nibisz
>> Aleďż˝ jedno drugiemu tak bardzo nie przeszkadza. Patrz: D.
>
> to nie jest C++ . Powtarzam - nie ma prostego sposobu �eby w C++ opanowa�
> konflikt pomi�dzy istniejacymi deterministycznymi destruktorami a GC.
Czy nie wystarczy aby klasa definiowa�a jak b�dzie wo�any jej destruktor?
W przypadku deterministycznego destruktora, mo�na stosowa� zliczanie
referencji.
Pozdrawiam,
- Bastek -
Bronek Kozicki
nie, problemem s� podobiekty - one mog� wymaga� wo�ania destruktor�w.
Tej gwarancji nie mo�na wycofa� z j�zyka. Ponadto, problemem nie jest
"jak" ale "czy" - GC nie zapewnia wo�ania destruktora.
B.
Sebastian Nibisz
Mo�na zagwarantowa� wo�anie destruktora, to jest tylko kwestia przyj�cia
pewnych zasad.
Gdy zagwarantujemy wo�anie destruktora, nie b�dzie problem�w z niszczeniem
podobiekt�w.
Pozdrawiam,
- Bastek -
Marcin 'Qrczak' Kowalczyk
> Czy nie wystarczy aby klasa definiowała jak będzie wołany jej destruktor?
> W przypadku deterministycznego destruktora, można stosować zliczanie
> referencji.
Nie wystarczy, bo wtedy konieczność zliczania referencji rozciąga się
na wszystkie wskaźniki, które potencjalnie mogą wskazywać na coś
wymagające detreministycznego destruktora -- w szczególności na
wskaźniki na nadklasy z otwartym zbiorem możliwych podklas. Zatem
większość programu płaci za potencjalne możliwości wykorzystywane
tylko w znikomej części.
Sebastian Nibisz
> On 21 Gru, 22:21, "Sebastian Nibisz" <eb...@poczta.onet.pl> wrote:
>> W przypadku deterministycznego destruktora, mo�na stosowa� zliczanie
>> referencji.
>
> Nie wystarczy, bo wtedy konieczno�� zliczania referencji rozci�ga si�
> na wszystkie wska�niki, kt�re potencjalnie mog� wskazywa� na co�
> wymagaj�ce detreministycznego destruktora -- w szczeg�lno�ci na
> wska�niki na nadklasy z otwartym zbiorem mo�liwych podklas. Zatem
> wi�kszo�� programu p�aci za potencjalne mo�liwo�ci wykorzystywane
> tylko w znikomej cz�ci.
To za�o�enie jest ca�kowicie niepotrzebne. Deterministyczno�� powinna mie�
zasi�g lokalny a nie globalny.
Je�eli pole klasy posiada deterministyczny destruktor, to wcale nie oznacza,
�e klasa tak�e powinna taki posiada�. Tak� sytuacje mo�na zasygnalizowa� na
etapie kompilacji, ale powinna byďż˝ ona dozwolona. Nie trzeba wprowadzaďż˝
zb�dnych ogranicze�, tych wystarczy w j�zykach wy�szego poziomu.
Pozdrawiam,
- Bastek -
Sebastian Kaliszewski
> On 21/12/2009 11:07, Sebastian Kaliszewski wrote:
>>> Zauwa� powszechno�� konstrukcji try ... finally w programach w Javie -
>>> z tego samego powodu.
>>
>> Nie z tego samego. Wynika po prostu z braku nietrywialnych destruktor�w
>> i z faktu �e w Javie praktycznie ka�dy nietrywialny obiekt
>> (semantycznie) l�duje na stercie.
>
> no w�a�nie deterministyczne destruktory s� semantycznie niezgodne z GC.
Nie s�. Obiekty podlegaj�ce GC "logicznie" �yj� wiecznie i nie podlegaj�
destrukcji.
>>> To jest te� pow�d dlaczego C++0x nie ma pe�noprawnego GC - nie by�o
>>> prostego sposobu �e zagwarantowa� wsp�prac� z RAII.
>>
>> Aleďż˝ jedno drugiemu tak bardzo nie przeszkadza. Patrz: D.
>
> to nie jest C++ . Powtarzam - nie ma prostego sposobu �eby w C++
> opanowa� konflikt pomi�dzy istniejacymi deterministycznymi destruktorami
> a GC.
Aleďż˝ jest. Zresztďż˝ przecieďż˝ zostaďż˝ opanowany.
Sebastian Nibisz
>> no w�a�nie deterministyczne destruktory s� semantycznie niezgodne z GC.
>
> Nie s�. Obiekty podlegaj�ce GC "logicznie" �yj� wiecznie i nie podlegaj�
> destrukcji.
To jest tylko jeden z mo�liwych wariant�w. Mo�na zapewni� wo�anie
destruktor�w przez GC i wtedy obiekty wiecznie �y� nie b�d�.
Czyďż˝ stos nie jest namiastkďż˝ prymitywnego GC?
Pozdrawiam,
- Bastek -
Sebastian Kaliszewski
> to nie jest C++ . Powtarzam - nie ma prostego sposobu �eby w C++
> opanowa� konflikt pomi�dzy istniejacymi deterministycznymi destruktorami
> a GC.
Napisz� wi�cej:
Oczywi�cie �e spos�b jest, ba nawet s� co najmniej 3. I jak rozumiem
jeden z nich zreszt� u�yto w przygotowywanym standardzie.
1. Destruktor nie jest deterministyczny (dotyczy obiekt�w alokowanych
*bezpo�rednio* na stercie od�miecanej) ale jest wo�any zawsze (poza
paroma bardzo szczeg�lnymi przypadkami typu globalny czy statyczny
wiecznie �ywy wska�nik). Pozosta�e obiekty (w tym obiekty "wbudowane" w
inne czyli ich pola) maj� destruktory wo�ane deterministycznie wzgl�dem
destruktora obiektu opakowuj�cego lub je�li takiego nie ma (czyli s� to
obiekty kt�re maj� "klasyczne storage") to maj� wo�ane "po staremu".
Rozwi�zanie teoretycznie brzydkie: wad� ma tak�, �e w czasie destrukcji
wska�niki na inne obiekty z od�miecanej sterty mog� dynda� -- czyli nie
wolno w destruktorze odwo�ywa� si� przez wska�niki sterty GC do
czegokolwiek (ale je�li realizowane by�oby nie jako obca biblioteka
tylko blisko kompilatora -- w nim samym lub w runtime i bibliotece
standardowej -- to mo�na by przynajmniej warningi generowa� i w trybie
debug czysto wywalaďż˝ aplikacjďż˝).
Nie mniej jednak to w�a�nie to rozwi�zanie jest w moim od�miecaczu i,
jak rozumiem, w od�miecaczu mojego imiennika. Po prostu w od�miecaczach
pracuj�cych na smart pointerach nie bardzo widz� inne rozwi�zanie (ale
mo�e Piotr Wyderski widzi i sprostuje :) )
2. Obiekt od�miecany logicznie �yje wiecznie -- nie ma destrukcji i ju�.
Je�li obiekt sta� si� �mieciem to mo�na zwolni� jego pami��, ale
logicznie on nadal istnieje tylko jest nieosi�galny, po finalizacji nikt
ju� nigdy do jego danych nie si�gnie. innymi s�owy GC staje si� (bardzo
zgrubnym) przybli�eniem niesko�czonej pami�ci. Rozwi�zanie teoretycznie
eleganckie, ale ma wad� o jakiej m�wi�e� -- wbudowane obiekty r�wnie�
nigdy nie s� niszczone i je�li one mia�y jakie� zaalokowane zasoby to
ich nie zwolni�. Rozwi�zanie zatem oznacza, �e programista musi inaczej
zadba� o zwalnianie zasob�w innych ni� pami��, skojarzonych z obiektami
od�miecanymi -- np. poprzez finalizatory (i w nich jawnie dokona�
destrukcji p�l obiektu tego wymagaj�cych). Wszytko to k�opotliwe i
b�edogenne (je�li projektanci j�zyka schrzani� finalizacj� -- tak jak
schrzaniono j� w Javie i C# -- to b�dzie bardziej b��dogennie, je�li za�
rozwi��� to dobrze to b�dzie nieco lepiej).
Jak rozumiem to w�a�nie takie rozwi�zanie przyj�to w opcjonalnym GC dla
nowego C++.
3. Obiekty maj� wo�ane destruktory i to deterministycznie -- mamy po
prostu zliczanie referencji. Dodatkowo mamy od�miecacz cykli, kt�ry
destruktor�w ju� nie wo�a. Wada taka, �e zliczanie referencji si�
�rednio skaluje w dodatku w wypadku C++ jest kupa parszywych "corner
cases" w rodzaju tablica POD�w i wska�niki do jej �rodka (a ka�dy
o�miecany obiekt musia�by mie� licznik referencji z nim skojarzony).
W przypadku 2 finalizazja jest kluczowa (i jej dobre rozwi�zanie te�
jest kluczowe), w pozosta�ych (1 i 3) finalizacja mo�e by� dodana, ale
mo�na bez niej �y� (i mniejszym b�lem jest jej z�e rozwi�zanie).
Sebastian Nibisz
> Oczywi�cie �e spos�b jest, ba nawet s� co najmniej 3. I jak rozumiem jeden
> z nich zreszt� u�yto w przygotowywanym standardzie.
Ja zaimplementowa�em wariant 1 + 3.
Standardowo realizowany jest wariant 1, ale gdy klasa dziedziczy po klasie
Limited, destruktor wo�any jest deterministycznie.
Pozdrawiam,
- Bastek -
Marcin 'Qrczak' Kowalczyk
> Deterministyczność powinna mieć zasięg lokalny a nie globalny.
Lokalnie masz Dispose i using i możemy się spierać tylko o lukier
składniowy.
> Jeżeli pole klasy posiada deterministyczny destruktor, to wcale nie oznacza,
> że klasa także powinna taki posiadać. Taką sytuacje można zasygnalizować na
> etapie kompilacji, ale powinna być ona dozwolona.
Bez sensu. W takim przypadku "deterministyczny" destruktor pola będzie
wołany niedeterministycznie.
Sebastian Nibisz
>> Deterministyczno�� powinna mie� zasi�g lokalny a nie globalny.
>
> Lokalnie masz Dispose i using i mo�emy si� spiera� tylko o lukier
> sk�adniowy.
Automatyczna destrukcja lokalnych zmiennych teďż˝ jest lukrem?
>> Je�eli pole klasy posiada deterministyczny destruktor, to wcale nie
>> oznacza,
>> �e klasa tak�e powinna taki posiada�. Tak� sytuacje mo�na zasygnalizowa�
>> na
>> etapie kompilacji, ale powinna byďż˝ ona dozwolona.
>
> Bez sensu. W takim przypadku "deterministyczny" destruktor pola b�dzie
> wo�any niedeterministycznie.
I co z tego? Bedzie wo�any deterministycznie wzgl�dem obiektu nadrz�dnego.
Skoro taka wola programisty, to nie widz� w tym nic z�ego.
Pozdrawiam,
- Bastek -
Piotr Wyderski
> 1.
Ja mam i 1 i 3, ale jako osobne od�miecacze -- wybiera
si� odpowiedni do rozwi�zywanego problemu, przy czym
zazwyczaj jest to 3, czyli proste intruzywne zliczanie
referencji. Od�miecacz niedeterministyczny jak dot�d
znalaz� zastosowanie jedynie w dw�ch analizatorach
graf�w, ze wzgl�du na ich potencjaln� cykliczno��.
> Rozwi�zanie teoretycznie brzydkie: wad� ma tak�, �e w czasie destrukcji
> wska�niki na inne obiekty z od�miecanej sterty mog� dynda� -- czyli nie
> wolno w destruktorze odwo�ywa� si� przez wska�niki sterty GC do
> czegokolwiek
W praktyce to nie jest istotna wada, bo zachodzďż˝ dwa przypadki:
a) niszczony podgraf okazuje siďż˝ byďż˝ acykliczny, a wtedy
wystarczy wykonaďż˝ sortowanie topologiczne i niszczyďż˝ w tej
kolejno�ci -- operowanie na wska�nikach sk�adowych b�dzie
bezpieczne.
b) wyst�puje cykl, a przy jego niszczeniu kt�ry� obiekt
po prostu musi sta� si� tym pierwszym w kolejce. To mo�na
wykryďż˝ dynamicznie i awaryjnie zatrzymaďż˝ program
z odpowiednim wpisem do log�w, zawieraj�cym m.in.
pe�n� �cie�k� w grafie zale�no�ci. Po ustaleniu winnego
stosunkowo �atwo mo�na poprawi� b��d.
Mo�na te� si� nie przejmowa� analiz� graf�w i w ciemno
zdecydowaďż˝ siďż˝ na robienie zawsze wariantu (b) -- gc_ptr
w destruktorach to �redni pomys�.
> Nie mniej jednak to w�a�nie to rozwi�zanie jest w moim od�miecaczu i, jak
> rozumiem, w od�miecaczu mojego imiennika.
I u mnie te�. A skoro trzech ludzi niezale�nie dosz�o do
jednakowych wniosk�w, z powodzeniem implementuj�c
ten wariant w rzeczywi�cie istniej�cych systemach, to
wida� jest to w�a�ciwe rozwi�zanie problemu. :-)
> 3. Obiekty maj� wo�ane destruktory i to deterministycznie -- mamy po
> prostu zliczanie referencji. Dodatkowo mamy od�miecacz cykli, kt�ry
> destruktor�w ju� nie wo�a.
Mo�na w trywialny spos�b zabroni� powstawania cykli,
a robi si� to poprzez u�ycie wska�nik�w const. W�wczas
kompilator wymusi ich inicjalizacjďż˝ w konstruktorze, a do
konstruktora mo�na przekaza� tylko wska�niki na ju�
skonstruowane obiekty. Na pierwszy rzut oka wydaje siďż˝
to byďż˝ znacznym ograniczeniem, ale w praktyce okazuje
si� zaskakuj�co uniwersalne -- jest to m�j podstawowy
spos�b zarz�dzania zasobami dynamicznymi. Gdy nie
wystarcza, to oznacza, �e potrzebuj� zupe�nie innego
algorytmu, tj. mark&sweep -- znam algorytmy RC radz�ce
sobie z cyklami, ale zaliczam je do kategorii "baba z brodďż˝"
i nie stosujďż˝. :-)
Dlatego w�a�nie mam dwa podsystemy GC.
> Wada taka, �e zliczanie referencji si� �rednio skaluje
W implementacji naiwnej owszem, ale opisywa�em kiedy�,
jak zrobi�, by si� �wietnie skalowa�o. Kto powiedzia�, �e
licznik referencji ma zawsze wyst�powa� w jednej kopii? :-)
Pozdrawiam
Piotr Wyderski
Bronek Kozicki
> Bronek Kozicki wrote:
>> On 21/12/2009 21:21, Sebastian Nibisz wrote:
>>> Czy nie wystarczy aby klasa definiowa�a jak b�dzie wo�any jej
>>> destruktor?
>>> W przypadku deterministycznego destruktora, mo�na stosowa� zliczanie
>>> referencji.
>>
>> nie, problemem s� podobiekty - one mog� wymaga� wo�ania destruktor�w.
>> Tej gwarancji nie mo�na wycofa� z j�zyka. Ponadto, problemem nie jest
>> "jak" ale "czy" - GC nie zapewnia wo�ania destruktora.
>
> Mo�na zagwarantowa� wo�anie destruktora, to jest tylko kwestia przyj�cia
> pewnych zasad.
wielu pr�bowa�o, nikomu si� nie uda�o. Chyba �e masz na my�li zasady w
rodzaju "destruktor mo�e by� wo�any zero lub wi�cej razy w przypadkowym
w�tku".
B.
Bronek Kozicki
> Marcin 'Qrczak' Kowalczyk wrote:
>> Bez sensu. W takim przypadku "deterministyczny" destruktor pola b�dzie
>> wo�any niedeterministycznie.
>
> I co z tego? Bedzie wo�any deterministycznie wzgl�dem obiektu nadrz�dnego.
> Skoro taka wola programisty, to nie widz� w tym nic z�ego.
kt�rego programisty? Tego kt�ry napisa� klas� kt�ra "zadeklarowa�a" �e
mo�e by� GC , czy te� ka�dej z tych ktore s� jej podobiektami?
B.
Sebastian Nibisz
> wielu pr�bowa�o, nikomu si� nie uda�o. Chyba �e masz na my�li zasady w
> rodzaju "destruktor mo�e by� wo�any zero lub wi�cej razy w przypadkowym
> w�tku".
Przyjmuj� za�o�enie, �e destruktor jest wo�any zawsze, ale mo�e sie to odby�
w osobnym w�tku.
Pozdrawiam,
- Bastek -
Sebastian Nibisz
Zgodnie z hierarchiďż˝.
Autor klasy decyduje o sposobie jej destrukcji. Je�eli umieszcza w klasie
pola innych klas, to robi to �wiadomie i wie jak te pola s� niszczone.
Pozdrawiam,
- Bastek -
Sebastian Nibisz
>Je�eli umieszcza w klasie pola innych klas.
Mia�o by�:
Je�eli umieszcza w klasie pola innego typu.
Bronek Kozicki
... to autor tego innego typu musi bardzo uwa�a� �eby jego destruktor
da� si� wykona� w innym w�tku w tej i w przysz�ych wersjach, bo inaczej
popsuje programy u�ytkownik�w. Np. nigdy nie b�dzie m�g� zwolni� �adnego
obiektu synchronizacji w destruktorze, je�eli obecna wersja tego nie robi.
To ja dziekujďż˝.
B.
Sebastian Nibisz
> ... to autor tego innego typu musi bardzo uwa�a� �eby jego destruktor da�
> si� wykona� w innym w�tku w tej i w przysz�ych wersjach, bo inaczej
> popsuje programy u�ytkownik�w. Np. nigdy nie b�dzie m�g� zwolni� �adnego
> obiektu synchronizacji w destruktorze, je�eli obecna wersja tego nie robi.
>
> To ja dziekujďż˝.
Po pierwsze, mo�na zaznaczy�, �e obiekt musi by� zwalniany deterministycznie
w w�tku programu i wtedy dba sie o to aby by� niszczony w taki spos�b.
Po drugie, trend idzie w kierunku przetwarzania r�wnoleg�ego, wi�c i tak
pr�dzej czy p�niej o synchronizacj� trzeba b�dzie dba�.
Teraz efekt jest taki, �e konserwatywne my�lenie blokuje rozw�j j�zyka w
obszarze GC.
Pozdrawiam,
- Bastek -
arturbac
> Po drugie, trend idzie w kierunku przetwarzania r�wnoleg�ego, wi�c i tak
> pr�dzej czy p�niej o synchronizacj� trzeba b�dzie dba�.
>
Pracujac na kodach dedykowany dla 4 - 16 rdzeni nauczylem siďż˝ iďż˝
synchronizacji musi by� jak najmniej, du�a granulacja osobne zasoby per
thread, a najlepiej model rozproszony je�li chce liniow� skalowalno��.
> Teraz efekt jest taki, �e konserwatywne my�lenie blokuje rozw�j j�zyka w
> obszarze GC.
Chwa�a im za to.
Sebastian Nibisz
> Fuj.
> Pracujac na kodach dedykowany dla 4 - 16 rdzeni nauczylem siďż˝ iďż˝
> synchronizacji musi by� jak najmniej, du�a granulacja osobne zasoby per
> thread, a najlepiej model rozproszony je�li chce liniow� skalowalno��.
A ile Twoim zdaniem tej synchronizacji potrzeba? Mo�esz mi poda� procentowo,
ile kodu w destruktorze b�dzie wymaga�o synchronizacji?
Pisa�em ju�, �e kod w destruktorze mo�e nie wymaga� synchronizacji, je�eli
si� o to zadba. Dlaczego nie chce sie da� programi�cie wyboru, tylko stara
siďż˝ decydowaďż˝ za niego?
>> Teraz efekt jest taki, �e konserwatywne my�lenie blokuje rozw�j j�zyka w
>> obszarze GC.
>
> Chwa�a im za to.
Najwy�ej za to, �e j�zyk b�dzie traci� na popularno�ci, bo przez wiele lat
praktycznie siďż˝ nie rozwija.
Pozdrawiam,
- Bastek -
Sebastian Kaliszewski
Cďż˝, Design by Comitee(tm).
Sebastian Kaliszewski
> On 22/12/2009 22:03, Sebastian Nibisz wrote:
>> Sebastian Nibisz wrote:
>>> Je�eli umieszcza w klasie pola innych klas.
>>
>> Mia�o by�:
>> Je�eli umieszcza w klasie pola innego typu.
>
> ... to autor tego innego typu musi bardzo uwa�a� �eby jego destruktor
> da� si� wykona� w innym w�tku w tej i w przysz�ych wersjach, bo inaczej
> popsuje programy u�ytkownik�w.
Je�li s� w�tki to i tak musi. W nowym C++ (w ko�cu) jest wielow�tkowo��,
stosowny model pami�ci, stosowne rozwi�zania biblioteczne itd. Je�li
natomiast w�tk�w nie ma to nie musi -- GC wcale nie musi by� w osobnym
w�tku.
> Np. nigdy nie b�dzie m�g� zwolni� �adnego
> obiektu synchronizacji w destruktorze, je�eli obecna wersja tego nie robi.
>
> To ja dziekujďż˝.
Dzi�kujesz za w�tki w C++? G�osowa�e� "w komitecie" przeciw? ;)
Sebastian Kaliszewski
>> Teraz efekt jest taki, �e konserwatywne my�lenie blokuje rozw�j j�zyka
>> w obszarze GC.
>
> Chwa�a im za to.
Nie ma za co. Po pierwsze dodali w�tki, wi�c i tak obiekty mog� by�
niszczone w innym w�tku ni� powsta�y. Po drugie GC *nie potrzebuje*
innych w�tk�w.
Sebastian Kaliszewski
Oczywi�cie, �e tego kt�ry zadeklarowa� �e jego klasa mo�e by� GC.
My�lisz �e dzi� jest jako� inaczej? Je�li zaakceptujesz istnienie w�tk�w
(nadchodz�cy standard w ko�cu akceptuje, wielu programist�w
zaakceptowa�o ju� dawno, jeszcze przed pierwszym standardem) to musisz
zaakceptowa�, �e obiekty b�d� mi�dzy tymi w�tkami przekazywane, czyli
b�d� niszczone w innym w�tku ni� powsta�y.
M�wisz o problemie kt�ry nie jest problemem. Problemem mo�e by� to �e
niekt�ry obiekty (podkre�lam: niekt�re) mog� wymaga� ograniczenia miejsc
gdzie mog� by� alokowane -- istotna jest mo�liwo�� oznaczenia typu
(klasy) jako nieprzeno�nego mi�dzy w�tkami analogicznie do tego jak dzi�
oznacza si� np. typy kt�rych obiekty s� niekopiowalne. Tyle.
A co do GC to w og�le nie wymaga destrukcji w innym w�tku ni� w�tek w
kt�rym obiekt powsta� bo w og�le nie ma konieczno�ci u�ycia w�tk�w.
pzdr
Marcin 'Qrczak' Kowalczyk
<s.bez_sp...@remove.this.informa.and.that.pl> wrote:
> Po drugie GC *nie potrzebuje* innych wątków.
Potrzebuje. Patrz: Hans-J Boehm "Destructors, Finalizers, and
Synchronization" (2003), rozdział 3.5.
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.4159
Sebastian Kaliszewski
> On 23 Gru, 10:13, Sebastian Kaliszewski
> <s.bez_sp...@remove.this.informa.and.that.pl> wrote:
>
>
> Potrzebuje.
Nie potrzebuje, bo nie potrzbuje w og�le wielu w�tk�w -- tj mo�na mie�
GC w j�zyku jednow�tkowym.
> Patrz: Hans-J Boehm "Destructors, Finalizers, and
> Synchronization" (2003), rozdziaďż˝ 3.5.
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.4159
Po pierwsze problemu nie ma w og�le gdy nie ma wielu w�tk�w. Po drugie
za�, w tym samym rozdziale napisane jest, �e problem tak samo dotyczy
zwyk�ego shared_ptr -- co jest oczywi�cie prawd�[*] ale co, jak praktyka
pokazuje, mo�na �mia�o dopu�ci�. C�, w tej sytuacji ca�y rzeczony
rozdzia� mo�na �mia�o przenie�� na p�k� z Opowie�ciami z Mchu i Paproci.
[*]
{
my_auto_lock lock(foo_nonreentrant_lock);
// destruktor my_type te� u�ywa foo_nonreentrant_lock
shared_ptr<my_type> foo = get_foo();
bar(foo);
whatever_else(foo);
} // bang!
Jako� nigdy na taki przypadek nie trafi�em, cho� programuj� od 20 lat...
Przypomnijmy na dodatek, �e m�wimy o destruktorach a nie finalizatorach
i �e nale�y pami�ta�, �e w destruktorze w og�le nie powinno si� robi�
operacji kt�re np. mog�yby wyrzuci� wyj�tek.
Prawda jest taka, �e w C++ nie da si� zrobi� dowolnego GC z dowolnie
silnie zabezpieczonego przed wszystkim. Ale da si� zrobi� u�yteczny i
dzia�aj�cy GC. I to r�wnie� w wielu w�tkach.
pzdr
Marcin 'Qrczak' Kowalczyk
<s.bez_sp...@remove.this.informa.and.that.pl> wrote:
> >> Po drugie GC *nie potrzebuje* innych wątków.
>
> > Potrzebuje.
>
> Nie potrzebuje, bo nie potrzbuje w ogóle wielu wątków -- tj można mieć
> GC w języku jednowątkowym.
Ale tylko o ograniczonej funkcjonalności: bez finalizatorów albo
wymagający kodowania dodatków poza językiem albo z finalizatorami, w
których nie bardzo wiadomo, co jest bezpieczne do użycia.
W szczególności nie można mieć finalizatora, który operuje na
globalnej strukturze danych -- chyba że mamy skądś gwarancję, że
operacje na tej strukturze są atomowe i że finalizator nie zostanie
odpalony w czasie takiej operacji (np. że jedyne takie operacje są w
jądrze systemu, a odśmiecacz działa w przestrzeni użytkownika).
> Po pierwsze problemu nie ma w ogóle gdy nie ma wielu wątków.
Jest. Problem się ujawnia, kiedy finalizator operujący na jakiejś
strukturze danych zostaje odpalony w trakcie innej operacji na tej
samej strukturze danych i przynajmniej jedna z tych operacji jest
operacją zapisu (wykluczającą współbieżne inne operacje).
Sebastian Kaliszewski
> On 23 Gru, 13:07, Sebastian Kaliszewski
> <s.bez_sp...@remove.this.informa.and.that.pl> wrote:
>
>>> Potrzebuje.
>> Nie potrzebuje, bo nie potrzbuje w og�le wielu w�tk�w -- tj mo�na mie�
>> GC w j�zyku jednow�tkowym.
>
> wymagaj�cy kodowania dodatk�w poza j�zykiem albo z finalizatorami, w
> kt�rych nie bardzo wiadomo, co jest bezpieczne do u�ycia.
No w�a�nie nie.
>
> W szczeg�lno�ci nie mo�na mie� finalizatora, kt�ry operuje na
> globalnej strukturze danych -- chyba �e mamy sk�d� gwarancj�, �e
> operacje na tej strukturze s� atomowe i �e finalizator nie zostanie
> odpalony w czasie takiej operacji (np. �e jedyne takie operacje s� w
> j�drze systemu, a od�miecacz dzia�a w przestrzeni u�ytkownika).
>
>> Po pierwsze problemu nie ma w og�le gdy nie ma wielu w�tk�w.
>
> Jest. Problem si� ujawnia, kiedy finalizator operuj�cy na jakiej�
> strukturze danych zostaje odpalony w trakcie innej operacji na tej
> samej strukturze danych i przynajmniej jedna z tych operacji jest
> operacj� zapisu (wykluczaj�c� wsp�bie�ne inne operacje).
Finalizator ot tak sobie nie operuje na jakiejďż˝ strukturze.
Problem jest stary jak przerwania i oczywi�cie zosta� rozwi�zany (na
kilka spos�b�w). Problem dotyczy obs�ugi wszelkich zdarze� asynchronicznych.
Najprostszy spos�b to to, �e na czas operacji na potencjalnie gro�nej
strukturze zabraniamy finalizacji.
twardy C
> Sebastian Kaliszewski wrote:
>>> no właśnie deterministyczne destruktory są semantycznie niezgodne z
>>> GC.
>>
>> Nie są. Obiekty podlegające GC "logicznie" żyją wiecznie i nie
>> podlegają destrukcji.
>
> To jest tylko jeden z możliwych wariantów. Można zapewnić wołanie
> destruktorów przez GC i wtedy obiekty wiecznie żyć nie będą. Czyż stos
> nie jest namiastką prymitywnego GC?
może z innej strony— stos jest praktyczną implementacją struktury danych
wyrażającą urządzenie składowania danych pośrednich programu w procedu-
ralnym przepływie wykonania. menedżer pamięci typu ‛zarządzający pa-
mięcią zmiennych programu’ (tzw. ‘garbage collector’) nie wiąże, ale ro-
związuje tę zależność względem przepływu wykonania.
--
―oh yea, i got it!
―oh, stupid!
D. Icke
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Bronek Kozicki
> Bronek Kozicki wrote:
>> ... to autor tego innego typu musi bardzo uwa�a� �eby jego destruktor
>> da� si� wykona� w innym w�tku w tej i w przysz�ych wersjach, bo
>> inaczej popsuje programy u�ytkownik�w. Np. nigdy nie b�dzie m�g�
>> zwolni� �adnego obiektu synchronizacji w destruktorze, je�eli obecna
>> wersja tego nie robi.
>>
>> To ja dziekujďż˝.
>
> Po pierwsze, mo�na zaznaczy�, �e obiekt musi by� zwalniany
> deterministycznie w w�tku programu i wtedy dba sie o to aby by�
> niszczony w taki spos�b.
my�la�em o tym. Nie da�o si� zrobi� prosto.
B.
Bronek Kozicki
>
> Dzi�kujesz za w�tki w C++? G�osowa�e� "w komitecie" przeciw? ;)
tak.
B.
Bronek Kozicki
>
>> destruktorze, je�eli obecna wersja tego nie robi.
>>
>> To ja dziekujďż˝.
>
> Dzi�kujesz za w�tki w C++? G�osowa�e� "w komitecie" przeciw? ;)
g�osowa�em przeciw GC, nie w�tkom.
B.
Sebastian Nibisz
To nie jest proste, ale gra jest warta �wieczki.
W moim przekonaniu, j�zyk C++ bez prawdziwego GC nie ma �wietlanej
przysz�o�ci. Jego pole zastosowa� bardzo si� ograniczy.
Zliczanie referencji nie jest dobrďż˝ alternatywďż˝, gdyďż˝ nie jest w 100%
skuteczne a w przypadku aplikacji wielow�tkowych, du�o mniej wydajne.
Ciekaw jestem, dlaczego jest taki wielki op�r przed wprowadzeniem
opcjonalnego GC do j�zyka. Nic si� przecie� nie traci a wiele mo�na zyska�.
Pozdrawiam,
- Bastek -
Bronek Kozicki
> Ciekaw jestem, dlaczego jest taki wielki op�r przed wprowadzeniem
> opcjonalnego GC do j�zyka. Nic si� przecie� nie traci a wiele mo�na zyska�.
bo jest to eksperyment - jeszcze �aden j�zyk nie ma dobrego GC, kt�ry
gwarantowa�by wykonania destruktora dok�adnie raz. Do standardu ISO nie
wprowadza si� eksperyment�w, a tym bardziej takich s� technicznie
sprzeczne z obecnym standardem. Przyk�ad?
Za��my �e kto� potrafi�by napisa� dobry GC, taki kt�ry gwarantuje
wykonania destruktora zawsze i dok�adnie raz (.NET ani Java tego nie
potrafi�, ale mo�e znajdzie si� geniusz). Jedyna wada - GC dzia�a�by we
w�asnym w�tku. Za��my �e mamy klas� kt�ra zosta�a napisana przed
powstaniem GC kt�ra tylko zwalnia pami�� w destruktorze - a wi�c jest
zgodna z GC. U�ytkownicy nowych kompilator�w zaczynaj�c u�ywa� tej klasy
(a bardziej realnie - ca�ych istniej�cych bibliotek o takim zachowaniu)
i wszystko jest cacy. Do momentu a� rzeczona klasa musi zwolni� pami��
szybko (bo nagle zrobi�o si� bardzo du�o obiekt�w) ; musi zwolni� inny
rodzaj zasob�w (i to te� szybko, bo inne programy czekaj�) albo musi
zwolni� obiekty synchronizacji mi�dzyw�tkowej. Przyjmujesz zak�ady ile
program�w u�ytkownik�w zostanie zapsutych - bo zwalniaj� zasoby za
wolno, albo w z�ym w�tku? Oczywi�cie, autor rzeczonej klasy zna
rozwi�zanie - doda� metod� Dispose do r�cznego zwolnienia zasob�w, kt�ra
musi by� wo�ana przez u�ytkownika. I wtedy - voila! - idiom RAII
przestaje dzia�a� w programach w C++ , kt�re przeradzaj� si� w potworki
pe�ne try ... finally (bo razem z wprowadzeniem GC trzeba b�dzie doda�
"finally"), przeci�tny program wygl�da nie lepiej ni� pisany w Javie, a
na destruktory i RAII nikt ju� nie zwraca uwagi, bo "wszyscy wiedz�" �e
Dispose trzeba wo�a� r�cznie.
I juďż˝ po zawodach - nie ma C++ , jest kolejny klon Javy.
B.
Sebastian Nibisz
> On 24/12/2009 10:19, Sebastian Nibisz wrote:
>> Ciekaw jestem, dlaczego jest taki wielki op�r przed wprowadzeniem
>> opcjonalnego GC do j�zyka. Nic si� przecie� nie traci a wiele mo�na
>> zyskaďż˝.
>
> bo jest to eksperyment - jeszcze �aden j�zyk nie ma dobrego GC, kt�ry
> gwarantowa�by wykonania destruktora dok�adnie raz. Do standardu ISO nie
> wprowadza si� eksperyment�w, a tym bardziej takich s� technicznie
> sprzeczne z obecnym standardem. Przyk�ad?
Sory, ale ten eksperyment mo�na by�o ju� dawno wdro�y�, testowa� i
dopracowaďż˝.
Prawda jest taka, �e eksperymentowano z wieloma rzeczami a GC omijano
szerokim �ukiem. W my�l zasady - dobrzy programi�ci GC nie potrzebuj�.
> Za��my �e kto� potrafi�by napisa� dobry GC, taki kt�ry gwarantuje
> wykonania destruktora zawsze i dok�adnie raz (.NET ani Java tego nie
> potrafi�, ale mo�e znajdzie si� geniusz). Jedyna wada - GC dzia�a�by we
> w�asnym w�tku. Za��my �e mamy klas� kt�ra zosta�a napisana przed
> powstaniem GC kt�ra tylko zwalnia pami�� w destruktorze - a wi�c jest
> zgodna z GC. U�ytkownicy nowych kompilator�w zaczynaj�c u�ywa� tej klasy
> (a bardziej realnie - ca�ych istniej�cych bibliotek o takim zachowaniu) i
> wszystko jest cacy. Do momentu a� rzeczona klasa musi zwolni� pami��
> szybko (bo nagle zrobi�o si� bardzo du�o obiekt�w) ; musi zwolni� inny
> rodzaj zasob�w (i to te� szybko, bo inne programy czekaj�) albo musi
> zwolni� obiekty synchronizacji mi�dzyw�tkowej. Przyjmujesz zak�ady ile
> program�w u�ytkownik�w zostanie zapsutych - bo zwalniaj� zasoby za wolno,
> albo w z�ym w�tku? Oczywi�cie, autor rzeczonej klasy zna rozwi�zanie -
> doda� metod� Dispose do r�cznego zwolnienia zasob�w, kt�ra musi by� wo�ana
> przez u�ytkownika. I wtedy - voila! - idiom RAII przestaje dzia�a� w
> programach w C++ , kt�re przeradzaj� si� w potworki pe�ne try ... finally
> (bo razem z wprowadzeniem GC trzeba b�dzie doda� "finally"), przeci�tny
> program wygl�da nie lepiej ni� pisany w Javie, a na destruktory i RAII
> nikt ju� nie zwraca uwagi, bo "wszyscy wiedz�" �e Dispose trzeba wo�a�
> r�cznie.
Wyjd� z za�o�enia, �e obecny kod domy�lnie nie korzysta z GC. Tak jak to
pisa�em wcze�niej - o sposobie niszczenia obiektu w pierwszej kolejno�ci
powinien decydowaďż˝ autor klasy.
C++ mog�oby wspiera� trzy warianty r�wnocze�nie.
1. R�czne zarz�dzanie (domy�lne).
2. GC oparte o zliczanie referencji, dla obiekt�w niszczonych
deterministycznie.
3. Standardowe GC dla obiekt�w niszczonych niedeterministycznie.
Pozdrawiam,
- Bastek -
Bronek Kozicki
>> On 22/12/2009 23:04, Sebastian Nibisz wrote:
>>> Po pierwsze, mo�na zaznaczy�, �e obiekt musi by� zwalniany
>>> deterministycznie w w�tku programu i wtedy dba sie o to aby by�
>>> niszczony w taki spos�b.
>>
>> my�la�em o tym. Nie da�o si� zrobi� prosto.
>
> To nie jest proste, ale gra jest warta �wieczki.
> W moim przekonaniu, j�zyk C++ bez prawdziwego GC nie ma �wietlanej
> przysz�o�ci. Jego pole zastosowa� bardzo si� ograniczy.
ale� przeciwnie, to j�zyki bez deterministycznej destrukcji nie maj�
�wietlanej przysz�o�ci :-P
A to �e inne j�zyki pojawi� si� do obs�ugi zada� gdzie C++ specjalnie
si� nie nadaje (np GUI) to bardzo dobrze. Nikt nie ma za z�e
programistom C++ , �e relacyjne bazy danych lepiej robi si� w SQL. Po
prostu dobry programista ma wi�cej narz�dzi ni� jeden j�zyk.
B.
Bronek Kozicki
> Bronek Kozicki wrote:
>> On 24/12/2009 10:19, Sebastian Nibisz wrote:
>>> Ciekaw jestem, dlaczego jest taki wielki op�r przed wprowadzeniem
>>> opcjonalnego GC do j�zyka. Nic si� przecie� nie traci a wiele mo�na
>>> zyskaďż˝.
>>
>> bo jest to eksperyment - jeszcze �aden j�zyk nie ma dobrego GC, kt�ry
>> gwarantowa�by wykonania destruktora dok�adnie raz. Do standardu ISO
>> nie wprowadza si� eksperyment�w, a tym bardziej takich s� technicznie
>> sprzeczne z obecnym standardem. Przyk�ad?
>
> Sory, ale ten eksperyment mo�na by�o ju� dawno wdro�y�, testowa� i
> dopracowaďż˝.
chyba nie zrozumia�e� co napisa�em. Proces standaryzacyjne nie polega na
eksperymentowaniu. Je�eli kto� potrafi zrobi� eksperymentalny doskona�y
GC do C++ to niech go najpierw zrobi, zademonstruje jego dzia�anie i
pozwoli innym u�ytkownikom z niego korzysta� we w�asnych programach.
Dopiero kiedy b�dzie mo�na, na podstawie do�wiadczenia u�ytkownik�w,
oceni� jego dzia�anie i wsp�dzia�anie z innymi cechami j�zyka, dopiero
wtedy komitet rozwa�y wprowadzenie GC do j�zyka.
C++ to nie jest j�zyk nale��cy do jednej firmy, kt�ra mo�e si� wycofa� z
nieudanego eksperymentu - coďż˝ siďż˝ doda, prawie na pewno zostanie (np.
specyfikacja wyj�tk�w), razem z ca�ym skomplikowaniem j�zyka jakie
spowodowa�o. Co wi�cej, raz dodanej cechy j�zyka nie da si� nawet
modyfikowa�, je�eli mog�oby to zmieni� dzia�anie istniej�cych program�w.
> Wyjd� z za�o�enia, �e obecny kod domy�lnie nie korzysta z GC. Tak jak to
> pisa�em wcze�niej - o sposobie niszczenia obiektu w pierwszej kolejno�ci
> powinien decydowaďż˝ autor klasy.
>
> C++ mog�oby wspiera� trzy warianty r�wnocze�nie.
> 1. R�czne zarz�dzanie (domy�lne).
> 2. GC oparte o zliczanie referencji, dla obiekt�w niszczonych
> deterministycznie.
> 3. Standardowe GC dla obiekt�w niszczonych niedeterministycznie.
co� podobnego by�o powa�nie rozwa�ane. Okaza�o si� zbyt skomplikowane
�eby doda� do j�zyka, bez pewno�ci �e b�dzie dobrze dzia�a� - z powodu
braku do�wiadczenia.
Weso�ych �wi�t!
B.
Sebastian Nibisz
> chyba nie zrozumia�e� co napisa�em. Proces standaryzacyjne nie polega na
> eksperymentowaniu. Je�eli kto� potrafi zrobi� eksperymentalny doskona�y GC
> do C++ to niech go najpierw zrobi, zademonstruje jego dzia�anie i pozwoli
> innym u�ytkownikom z niego korzysta� we w�asnych programach. Dopiero kiedy
> b�dzie mo�na, na podstawie do�wiadczenia u�ytkownik�w, oceni� jego
> dzia�anie i wsp�dzia�anie z innymi cechami j�zyka, dopiero wtedy komitet
> rozwa�y wprowadzenie GC do j�zyka.
Ja to rozumiem, ale aby mo�na by�o zaproponowa� dobry system GC, potrzebne
jest przynajmniej cz�ciowe wsparcie ze strony j�zyka. �atwiej by�oby co�
opracowa�, gdyby by�o wiadomo, �e komitet mo�e takie wsparcie zagwarantowa�.
Nikt nie b�dzie traci� czasu na opracowywanie systemu GC w przypadku, gdy
komitet wprowadzenia GC do j�zyka nie planuje.
> C++ to nie jest j�zyk nale��cy do jednej firmy, kt�ra mo�e si� wycofa� z
> nieudanego eksperymentu - coďż˝ siďż˝ doda, prawie na pewno zostanie (np.
> specyfikacja wyj�tk�w), razem z ca�ym skomplikowaniem j�zyka jakie
> spowodowa�o. Co wi�cej, raz dodanej cechy j�zyka nie da si� nawet
> modyfikowa�, je�eli mog�oby to zmieni� dzia�anie istniej�cych program�w.
Zwa� na to, �e w r�nych kompilatorach wdra�ane s� rozwi�zania, kt�re
standardem jeszcze nie s�. S� one jednak rozwa�ane i proponowane do
wdro�enia, cho� wcale nie wiadomo, czy zostan� przyj�te jako standard. W
przypadku GC proponowanych rozwi�za� nie ma, dlatego te� nikt nie sprawdza
ich dzia�ania w praktyce.
>> C++ mog�oby wspiera� trzy warianty r�wnocze�nie.
>> 1. R�czne zarz�dzanie (domy�lne).
>> 2. GC oparte o zliczanie referencji, dla obiekt�w niszczonych
>> deterministycznie.
>> 3. Standardowe GC dla obiekt�w niszczonych niedeterministycznie.
>
> co� podobnego by�o powa�nie rozwa�ane. Okaza�o si� zbyt skomplikowane �eby
> doda� do j�zyka, bez pewno�ci �e b�dzie dobrze dzia�a� - z powodu braku
> do�wiadczenia.
Trudno zdoby� do�wiadczenie, gdy nie sprawdza si� rozwi�za� w praktyce. Z
drugiej strony nikt nie b�dzie ich sprawdza�, bez wyra�nej deklaracji ch�ci
ich wprowadzenia. Ko�o sie zamyka a systemu GC jak nie by�o tak nie ma.
> Weso�ych �wi�t!
Weso�ych �wi�t!
Pozdrawiam,
- Bastek -
Sebastian Nibisz
>> To nie jest proste, ale gra jest warta �wieczki.
>> W moim przekonaniu, j�zyk C++ bez prawdziwego GC nie ma �wietlanej
>> przysz�o�ci. Jego pole zastosowa� bardzo si� ograniczy.
>
> ale� przeciwnie, to j�zyki bez deterministycznej destrukcji nie maj�
> �wietlanej przysz�o�ci :-P
Zale�y od zastosowa�.
Obawiam sie, �e z czasem dojdzie do sytuacji, gdy je�yk C++ b�dzie stosowany
tylko tam, gdzie obecnie stosowany jest j�zyk C.
> A to �e inne j�zyki pojawi� si� do obs�ugi zada� gdzie C++ specjalnie si�
> nie nadaje (np GUI) to bardzo dobrze. Nikt nie ma za z�e programistom C++
> , �e relacyjne bazy danych lepiej robi si� w SQL. Po prostu dobry
> programista ma wi�cej narz�dzi ni� jeden j�zyk.
Ja bym wola� aby j�zyk C++ nadawa� sie dobrze do tworzenia GUI i mia�
standardowy zestaw bibliotek, dedykowanych do tego celu. Uwa�am, �e j�zyk
ten m�g�by posiada� mechanizmy wykorzystywane w innych j�zykach i m�g�by je
mieďż˝ zrealizowane lepiej.
Pozdrawiam,
- Bastek -
Sebastian Kaliszewski
> On 24/12/2009 10:19, Sebastian Nibisz wrote:
>> Bronek Kozicki wrote:
>>> On 22/12/2009 23:04, Sebastian Nibisz wrote:
>>>> Po pierwsze, mo�na zaznaczy�, �e obiekt musi by� zwalniany
>>>> deterministycznie w w�tku programu i wtedy dba sie o to aby by�
>>>> niszczony w taki spos�b.
>>>
>>> my�la�em o tym. Nie da�o si� zrobi� prosto.
>>
>> To nie jest proste, ale gra jest warta �wieczki.
>> W moim przekonaniu, j�zyk C++ bez prawdziwego GC nie ma �wietlanej
>> przysz�o�ci. Jego pole zastosowa� bardzo si� ograniczy.
>
> ale� przeciwnie, to j�zyki bez deterministycznej destrukcji nie maj�
> �wietlanej przysz�o�ci :-P
Maj�. J�zyki bez GC s� spychane do niszy.
> A to �e inne j�zyki pojawi� si� do obs�ugi zada� gdzie C++ specjalnie
> si� nie nadaje (np GUI) to bardzo dobrze. Nikt nie ma za z�e
> programistom C++ , �e relacyjne bazy danych lepiej robi si� w SQL. Po
> prostu dobry programista ma wi�cej narz�dzi ni� jeden j�zyk.
Dobrych programist�w jest ma�o...
Sebastian Kaliszewski
> On 24/12/2009 10:19, Sebastian Nibisz wrote:
>> Ciekaw jestem, dlaczego jest taki wielki op�r przed wprowadzeniem
>> opcjonalnego GC do j�zyka. Nic si� przecie� nie traci a wiele mo�na
>> zyskaďż˝.
>
> bo jest to eksperyment - jeszcze �aden j�zyk nie ma dobrego GC, kt�ry
> gwarantowa�by wykonania destruktora dok�adnie raz. Do standardu ISO nie
> wprowadza si� eksperyment�w, a tym bardziej takich s� technicznie
> sprzeczne z obecnym standardem. Przyk�ad?
>
> Za��my �e kto� potrafi�by napisa� dobry GC, taki kt�ry gwarantuje
> wykonania destruktora zawsze i dok�adnie raz (.NET ani Java tego nie
> potrafi�, ale mo�e znajdzie si� geniusz).
C++ i bez tego *nie gwarantuje*, �e destruktor zostanie zawo�any tylko raz.
Gwarancje w GC, nie s�absze ni� w C++ s� osi�galne (i ba, s�
realizowane). Ba, cho�by �mieciuch takie ma.
> Jedyna wada - GC dzia�a�by we
> w�asnym w�tku.
Teďż˝ nie musi.
> Za��my �e mamy klas� kt�ra zosta�a napisana przed
> powstaniem GC kt�ra tylko zwalnia pami�� w destruktorze - a wi�c jest
> zgodna z GC. U�ytkownicy nowych kompilator�w zaczynaj�c u�ywa� tej klasy
> (a bardziej realnie - ca�ych istniej�cych bibliotek o takim zachowaniu)
> i wszystko jest cacy. Do momentu a� rzeczona klasa musi zwolni� pami��
> szybko (bo nagle zrobi�o si� bardzo du�o obiekt�w) ; musi zwolni� inny
> rodzaj zasob�w (i to te� szybko, bo inne programy czekaj�) albo musi
> zwolni� obiekty synchronizacji mi�dzyw�tkowej. Przyjmujesz zak�ady ile
> program�w u�ytkownik�w zostanie zapsutych - bo zwalniaj� zasoby za
> wolno, albo w z�ym w�tku? Oczywi�cie, autor rzeczonej klasy zna
> rozwi�zanie - doda� metod� Dispose do r�cznego zwolnienia zasob�w, kt�ra
> musi by� wo�ana przez u�ytkownika.
Ale� sk�d. Rozwi�zanie jest banalnie proste. Nie nale�y w takim (i tylko
w takim, czyli w ok 5% przypadk�w w og�le) u�ywa� GC. Nikt nie chcia�
zabieraďż˝ klasycznego storage.
W dodatku, widz�, �e w og�le mylisz destrukcj� z finalizacj�.
> I wtedy - voila! - idiom RAII
> przestaje dzia�a� w programach w C++ , kt�re przeradzaj� si� w potworki
> pe�ne try ... finally (bo razem z wprowadzeniem GC trzeba b�dzie doda�
> "finally"), przeci�tny program wygl�da nie lepiej ni� pisany w Javie, a
> na destruktory i RAII nikt ju� nie zwraca uwagi, bo "wszyscy wiedz�" �e
> Dispose trzeba wo�a� r�cznie.
>
> I juďż˝ po zawodach - nie ma C++ , jest kolejny klon Javy.
Problem jest wyssany z palca. Patrz wy�ej.
Sebastian Kaliszewski
> Bronek Kozicki wrote:
>>> To nie jest proste, ale gra jest warta �wieczki.
>>> W moim przekonaniu, j�zyk C++ bez prawdziwego GC nie ma �wietlanej
>>> przysz�o�ci. Jego pole zastosowa� bardzo si� ograniczy.
>>
>> ale� przeciwnie, to j�zyki bez deterministycznej destrukcji nie maj�
>> �wietlanej przysz�o�ci :-P
>
> Zale�y od zastosowa�.
> Obawiam sie, �e z czasem dojdzie do sytuacji, gdy je�yk C++ b�dzie
> stosowany tylko tam, gdzie obecnie stosowany jest j�zyk C.
W rzeczy samej.
Sebastian Kaliszewski
> On 24/12/2009 15:57, Sebastian Nibisz wrote:
>> Bronek Kozicki wrote:
>>> On 24/12/2009 10:19, Sebastian Nibisz wrote:
>>>> Ciekaw jestem, dlaczego jest taki wielki op�r przed wprowadzeniem
>>>> opcjonalnego GC do j�zyka. Nic si� przecie� nie traci a wiele mo�na
>>>> zyskaďż˝.
>>>
>>> bo jest to eksperyment - jeszcze �aden j�zyk nie ma dobrego GC, kt�ry
>>> gwarantowa�by wykonania destruktora dok�adnie raz. Do standardu ISO
>>> nie wprowadza si� eksperyment�w, a tym bardziej takich s� technicznie
>>> sprzeczne z obecnym standardem. Przyk�ad?
>>
>> Sory, ale ten eksperyment mo�na by�o ju� dawno wdro�y�, testowa� i
>> dopracowaďż˝.
>
> chyba nie zrozumia�e� co napisa�em. Proces standaryzacyjne nie polega na
> eksperymentowaniu.
Taaak. Takie pora�ki jak szablony w obecnej postaci, extern
template,specyfikacje wyj�tk�w czy auto_ptr_ref.
> Je�eli kto� potrafi zrobi� eksperymentalny doskona�y
> GC do C++
Bez zmiany j�zyka nie da si� zrobi� doskona�ego. Da si� zrobi�
dzia�aj�cy co pokazano po wielokro�, ale �aden nie jest doskona�y.
Jak pokazuj� liczne przyk�ady (w tym Concepts) robienie rozszerze� przed
standardem to strata czasu.
> to niech go najpierw zrobi, zademonstruje jego dzia�anie i
> pozwoli innym u�ytkownikom z niego korzysta� we w�asnych programach.
GC s� u�ywane (i *dzia�aj�* -- w przeciwie�stwie do paru �ama�c�w ze
standardu C++) od 40 lat.
> Dopiero kiedy b�dzie mo�na, na podstawie do�wiadczenia u�ytkownik�w,
> oceni� jego dzia�anie i wsp�dzia�anie z innymi cechami j�zyka, dopiero
> wtedy komitet rozwa�y wprowadzenie GC do j�zyka.
Z takim podej�ciem do nowych cech, nie ma si� co dziwi�, �e C++0x kt�ry
mia� by� "prze�omem" niczym nie b�dzie -- ot zestaw lu�no powi�zanych
drobnych dodatk�w. Oraz w�tki, kt�rych i tak ma�o kto b�dzie u�ywa� po
Ceplusplusowemu -- to co b�dzie u�ywane to po prostu "uprawomocnienie"
praktyki o ponad dekadďż˝ starszej niďż˝ pierwszy standard...
>
> C++ to nie jest j�zyk nale��cy do jednej firmy, kt�ra mo�e si� wycofa� z
> nieudanego eksperymentu
To nie ma nic wsp�lnego z firm�. Wi�kszo�� j�zyk�w nie nale�y do �adnej
firmy,
> - coďż˝ siďż˝ doda, prawie na pewno zostanie (np.
> specyfikacja wyj�tk�w), razem z ca�ym skomplikowaniem j�zyka jakie
> spowodowa�o.
To nie ma nic wsp�lnego z firmami. To jest po prostu efekt przyj�tego
(postawionego na g�owie z punktu widzenia metody tworzenia j�zyk�w
programowania) sposobu tworzenia j�zyka.
> Co wi�cej, raz dodanej cechy j�zyka nie da si� nawet
> modyfikowa�, je�eli mog�oby to zmieni� dzia�anie istniej�cych program�w.
I to jest *zupe�nie*, *absolutnie* *bez* *sensu*. Zw�aszcza, �e pierwszy
standard drastycznie zmodyfikowa� istniej�ce praktyki[*] (nowe nag��wki,
wepchni�cie ca�ej biblioteki standardowej do przestrzeni nazw).
Wywalenie extern template czy specyfikacji wyj�tk�w to przy tym piku�.
Ten argument kompletnie siďż˝ nie trzyma kupy.
Ba, w innych j�zykach od dawna funkcjonuje eleganckie rozwi�zanie tego
problemu -- cechy przeznaczone do kasowania oznacza siďż˝ jako
"deprecated" i np. przed ich u�yciem wymaga si� od programisty jawnego
zadeklarowania, �e cech deprecared u�yje. Ot zwyk�a #pragama deprecated
czy insze #include <deprecated>.
[*] C++ jest starsze od swojego standardu o circa 15 lat. I nie ma co
udawa�, �e jak nie by�o standardu to nie by�o j�zyka.
>> Wyjd� z za�o�enia, �e obecny kod domy�lnie nie korzysta z GC. Tak jak to
>> pisa�em wcze�niej - o sposobie niszczenia obiektu w pierwszej kolejno�ci
>> powinien decydowaďż˝ autor klasy.
>>
>> C++ mog�oby wspiera� trzy warianty r�wnocze�nie.
>> 1. R�czne zarz�dzanie (domy�lne).
>> 2. GC oparte o zliczanie referencji, dla obiekt�w niszczonych
>> deterministycznie.
>> 3. Standardowe GC dla obiekt�w niszczonych niedeterministycznie.
>
> co� podobnego by�o powa�nie rozwa�ane. Okaza�o si� zbyt skomplikowane
> �eby doda� do j�zyka, bez pewno�ci �e b�dzie dobrze dzia�a� - z powodu
> braku do�wiadczenia.
Przede wszystkim to by�a pr�ba pogodzenia x r�nych pomys��w na zasadzie
"�eby nikogo nie urazi�". To i tak by�o lepsze ni� nic, ale c�,
pozosta�o nic.
Bronek Kozicki
by�e� obecny podczas dyskusji technicznych WG21 na ten temat? Ja tam
by�em, zabiera�em g�os, i nie pami�tam Twojej obecno�ci. Propozycja by�a
jedna (Bohem & Spertus) - a problem by� z pogodzeniem jej z RAII. Je�eli
znasz inn� wersj� wydarze�, to podaj swoje �r�d�o.
B.
Bronek Kozicki
> Bronek Kozicki wrote:
>> wykonania destruktora zawsze i dok�adnie raz (.NET ani Java tego nie
>> potrafi�, ale mo�e znajdzie si� geniusz).
>
> C++ i bez tego *nie gwarantuje*, �e destruktor zostanie zawo�any tylko raz.
gwarantuje. Alternatywďż˝ jest undefined behaviour.
> Ale� sk�d. Rozwi�zanie jest banalnie proste. Nie nale�y w takim (i tylko
> w takim, czyli w ok 5% przypadk�w w og�le) u�ywa� GC. Nikt nie chcia�
> zabieraďż˝ klasycznego storage.
>
> W dodatku, widz�, �e w og�le mylisz destrukcj� z finalizacj�.
Zgadza si�, upro�ci�em sprawy. GC nie ma destruktor�w.
>> I juďż˝ po zawodach - nie ma C++ , jest kolejny klon Javy.
>
> Problem jest wyssany z palca. Patrz wy�ej.
wyt�umacz jak zamierzasz pogodzi� klasy korzystaj�ce z GC z tymi kt�re
wymagajďż˝ RAII
B.
Sebastian Kaliszewski
> On 28/12/2009 09:35, Sebastian Kaliszewski wrote:
>> Bronek Kozicki wrote:
>>> On 24/12/2009 15:57, Sebastian Nibisz wrote:
>>> co� podobnego by�o powa�nie rozwa�ane. Okaza�o si� zbyt skomplikowane
>>> �eby doda� do j�zyka, bez pewno�ci �e b�dzie dobrze dzia�a� - z powodu
>>> braku do�wiadczenia.
>>
>> Przede wszystkim to by�a pr�ba pogodzenia x r�nych pomys��w na zasadzie
>> "�eby nikogo nie urazi�". To i tak by�o lepsze ni� nic, ale c�,
>> pozosta�o nic.
>
> by�e� obecny podczas dyskusji technicznych WG21 na ten temat? Ja tam
> by�em, zabiera�em g�os, i nie pami�tam Twojej obecno�ci.
A co to ma do tego co napisa�em?
> Propozycja by�a
> jedna (Bohem & Spertus) - a problem by� z pogodzeniem jej z RAII. Je�eli
> znasz inn� wersj� wydarze�, to podaj swoje �r�d�o.
Widzia�em sam� propozyj� w postaci "papieru" (elektronicznego). I
widzia�em co by�o dyskutowane wcze�niej (nieformalnie, np.
comp.std.c++). Propozycja nie wzi�a si� z powietrza.
By�a jaka by�a ale by�a.
Sebastian Kaliszewski
ale� to w�tki maj� "problem" o kt�rym piszesz (�e obiekt mo�e by�
niszczony w innym w�tku ni� powsta�)
Sebastian Kaliszewski
> On 28/12/2009 09:07, Sebastian Kaliszewski wrote:
>> Bronek Kozicki wrote:
>>> Za��my �e kto� potrafi�by napisa� dobry GC, taki kt�ry gwarantuje
>>> wykonania destruktora zawsze i dok�adnie raz (.NET ani Java tego nie
>>> potrafi�, ale mo�e znajdzie si� geniusz).
>>
>> C++ i bez tego *nie gwarantuje*, �e destruktor zostanie zawo�any tylko
>> raz.
>
> gwarantuje.
Ale� sk�d!
Ot cho�by:
struct foo
{
~foo() {}
}
int main()
{
foo* ptr = new foo();
}
Nie wpspominaj�c ju� o takich rzeczach jak cho�by unexpected(). abort()
itd...
> Alternatywďż˝ jest undefined behaviour.
Ale� sk�d! Powy�szy kawa�ek kodu nie ma �adnego UB.
>> Ale� sk�d. Rozwi�zanie jest banalnie proste. Nie nale�y w takim (i tylko
>> w takim, czyli w ok 5% przypadk�w w og�le) u�ywa� GC. Nikt nie chcia�
>> zabieraďż˝ klasycznego storage.
>>
>> W dodatku, widz�, �e w og�le mylisz destrukcj� z finalizacj�.
>
> Zgadza si�, upro�ci�em sprawy. GC nie ma destruktor�w.
>
>>> I juďż˝ po zawodach - nie ma C++ , jest kolejny klon Javy.
>>
>> Problem jest wyssany z palca. Patrz wy�ej.
>
> wyt�umacz jak zamierzasz pogodzi� klasy korzystaj�ce z GC z tymi kt�re
> wymagajďż˝ RAII
Ju� w tym w�tku by�o.
O tym czy obiekt wyl�duje na stercie od�miecanej decyduje programista
(tak samo jak decyduje o tym czy b�dzie to obiekt statyczny,
automatyczny, na stercie "kalsycznej", utworzony przez placement new, w
nowym C++ lokalny dla w�tku itd). Dodatkowo wyr�niamy typ wska�nika na
obiekt od�miecany (cho�by gc_ptr<whatever>) kt�ry nie jest POD.
Destruktor obiekt�w od�miecacnych nie jest deterministyczny (dotyczy
obiekt�w alokowanych *bezpo�rednio* na stercie od�miecanej) ale jest
wo�any praktycznie zawsze (zawsze, poza przypadkami typu globalny,
statyczny czy te� umieszczony na nieod�miecanej stercie wiecznie �ywy
wska�nik, itp -- gwarancje nie s�absze ni� dzi� w C++ dla bez
od�miecania.). Pozosta�e obiekty (w tym obiekty wkomponowane w inne
czyli ich pola) maj� destruktory wo�ane deterministycznie wzgl�dem
destruktora obiektu opakowuj�cego lub je�li takiego nie ma (czyli s� to
obiekty kt�re maj� "klasyczne storage") to maj� wo�ane "po staremu".
K�opot teoretycznie taki, �e w czasie destrukcji (tylko destrukcji)
wska�niki na inne obiekty z od�miecanej sterty (ale tylko takie) mog�
dynda� -- czyli nie wolno w destruktorze odwo�ywa� si� przez wska�niki
sterty GC (od�miecane) do czegokolwiek co nie ma zagwarantowane, �e jest
trzymane przez niezale�ny, �yj�cy wska�nik. Ale mo�na bez problemu
przynajmniej warningi generowaďż˝ i w trybie debug czysto wywalaďż˝
aplikacj� -- to i tak lepiej ni� wszechpanuj�ce UB without diagnostic.
To w�a�nie to rozwi�zanie jest w moim od�miecaczu i, jak rozumiem, w
od�miecaczu mojego imiennika oraz w jednym z od�miecaczy (tym
obs�uguj�cym cykle) Piotra Wyderskiego.
I jak ww. Piotr podsumowaďż˝:
"A skoro trzech ludzi niezale�nie dosz�o do
jednakowych wniosk�w, z powodzeniem implementuj�c
ten wariant w rzeczywi�cie istniej�cych systemach, to
wida� jest to w�a�ciwe rozwi�zanie problemu. :-) "
Bronek Kozicki
> Bronek Kozicki wrote:
>> On 28/12/2009 09:07, Sebastian Kaliszewski wrote:
>>> Bronek Kozicki wrote:
>>>> Za��my �e kto� potrafi�by napisa� dobry GC, taki kt�ry gwarantuje
>>>> wykonania destruktora zawsze i dok�adnie raz (.NET ani Java tego nie
>>>> potrafi�, ale mo�e znajdzie si� geniusz).
>>>
>>> C++ i bez tego *nie gwarantuje*, �e destruktor zostanie zawo�any
>>> tylko raz.
>>
>> gwarantuje.
>
> Ale� sk�d!
tak, to si� nazywa "memory leak" i zazwyczaj jest b��dem programisty.
Skoro zamierzasz dyskutowaďż˝ o takich duperelach to czemu wybierasz mnie
do tej dyskusji?
>> wyt�umacz jak zamierzasz pogodzi� klasy korzystaj�ce z GC z tymi kt�re
>> wymagajďż˝ RAII
>
> Ju� w tym w�tku by�o.
tak, zauwa�y�em co�, ale nie zauwa�y�em na ten temat dyskusji.
> "A skoro trzech ludzi niezale�nie dosz�o do
> jednakowych wniosk�w, z powodzeniem implementuj�c
... to mo�e trzech ludzi zaprezentowuje propozycj� w WG21???
Propozycja by�a jedna, Boehm & Spertus, je�eli uwa�asz �e by�o inaczej a
nie by�e� na miejscu to nie wiem sk�d si� Twoja wiedza wzi�a.
Je�eli przygotujesz lepsz� propozycj�, to mo�e ma ona jakie� szanse w
kolejnej wersji standardu. Gotowy dokument mo�esz przes�a� do BS, on
jest szefem EWG (Evolution Working Group) i podpowie co robiďż˝ dalej. Nie
licz na zmian� w tym cyklu do C++0x , ale je�eli si� postarasz to masz
szans� do nast�pnej wersji.
B.
Bronek Kozicki
> Bronek Kozicki wrote:
>> On 23/12/2009 09:09, Sebastian Kaliszewski wrote:
>>>
>>>> Np. nigdy nie b�dzie m�g� zwolni� �adnego obiektu synchronizacji w
>>>> destruktorze, je�eli obecna wersja tego nie robi.
>>>>
>>>> To ja dziekujďż˝.
>>>
>>> Dzi�kujesz za w�tki w C++? G�osowa�e� "w komitecie" przeciw? ;)
>>
>> g�osowa�em przeciw GC, nie w�tkom.
>
> ale� to w�tki maj� "problem" o kt�rym piszesz (�e obiekt mo�e by�
> niszczony w innym w�tku ni� powsta�)
i co jest powszechniej stosowane w istniej�cych programach C++ i pilniej
wymaga standaryzacji ? W�tki czy GC?
Nie, nie odpowiadaj.
B.
Sebastian Kaliszewski
Zatem dlaczego co� co nie jest problemem w przypadku w�tk�w naglestaje
si�problememw przypadku GC?
Piotr Wyderski
> Co wi�cej, raz dodanej cechy j�zyka nie da si� nawet modyfikowa�, je�eli
> mog�oby to zmieni� dzia�anie istniej�cych program�w.
Np. semantyka s�owa kluczowego "auto"? :-D
Pozdrawiam
Piotr Wyderski
Piotr Wyderski
> ... to mo�e trzech ludzi zaprezentowuje propozycj� w WG21???
Istniejďż˝ znacznie przyjemniejsze sposoby marnotrawienia czasu.
Prosi�e� mnie jaki� czas temu Bronku o napisanie swoich uwag
na temat zmian semantyki konstrukcji "= default". Po�wi�ci�em
czas i napisa�em. I co z tego wynik�o? Wielkie nic, nawet jednego
maila w odpowiedzi. W efekcie utwierdzi�em si� tylko w przekonaniu,
�e nale�y trzyma� si� mo�liwie daleko od projektowania przez komitet.
> Je�eli przygotujesz lepsz� propozycj�, to mo�e ma ona jakie�
> szanse w kolejnej wersji standardu.
Nie nale�y spodziewa� si� tego, �e wnuki b�d� pisa� w C++"1"x...
> Gotowy dokument mo�esz przes�a� do BS, on jest szefem
> EWG (Evolution Working Group) i podpowie co robiďż˝ dalej.
Trudno i�� za radami kogo�, kto niedawno sko�czy� g�osuj�c
przeciw swojej w�asnej, �e tak powiem,... koncepcji.
Pozdrawiam
Piotr Wyderski
Bronek Kozicki
> Bronek Kozicki wrote:
>
>> ... to mo�e trzech ludzi zaprezentowuje propozycj� w WG21???
>
> Istniejďż˝ znacznie przyjemniejsze sposoby marnotrawienia czasu.
> Prosi�e� mnie jaki� czas temu Bronku o napisanie swoich uwag
> na temat zmian semantyki konstrukcji "= default". Po�wi�ci�em
> czas i napisa�em. I co z tego wynik�o? Wielkie nic, nawet jednego
tak, masz racj�. By� mo�e dlatego �e, po przesuni�ciu issue do etapu
"Ready" brakuje ch�tnych �eby wraca� do pocz�tku. Szkoda �e nie
zauwa�y�e� tego problemu kilka mcy wcze�niej.
B.
Sebastian Kaliszewski
> On 28/12/2009 12:35, Sebastian Kaliszewski wrote:
>> Bronek Kozicki wrote:
>>> On 28/12/2009 09:07, Sebastian Kaliszewski wrote:
>>>> Bronek Kozicki wrote:
>>>>> Za��my �e kto� potrafi�by napisa� dobry GC, taki kt�ry gwarantuje
>>>>> wykonania destruktora zawsze i dok�adnie raz (.NET ani Java tego nie
>>>>> potrafi�, ale mo�e znajdzie si� geniusz).
>>>>
>>>> C++ i bez tego *nie gwarantuje*, �e destruktor zostanie zawo�any
>>>> tylko raz.
>>>
>>> gwarantuje.
>>
>> Ale� sk�d!
>
> tak, to si� nazywa "memory leak" i zazwyczaj jest b��dem programisty.
W wielu miejscach nie jest, ba jest robiony celowo (np. w cz�ci
rozwi�za� singleton�w).
> Skoro zamierzasz dyskutowaďż˝ o takich duperelach to czemu wybierasz mnie
> do tej dyskusji?
Stwierdzi�em 2 fakty:
1) �e gwarancji wywo�ania destruktora nie ma nie by�o i nie b�dzie
2) �e GC mo�e dawa� nie s�absze gwaranacje ni� te co teraz s�.
>
>>> wyt�umacz jak zamierzasz pogodzi� klasy korzystaj�ce z GC z tymi kt�re
>>> wymagajďż˝ RAII
>>
>> Ju� w tym w�tku by�o.
>
> tak, zauwa�y�em co�, ale nie zauwa�y�em na ten temat dyskusji.
>
>> "A skoro trzech ludzi niezale�nie dosz�o do
>> jednakowych wniosk�w, z powodzeniem implementuj�c
>
> ... to mo�e trzech ludzi zaprezentowuje propozycj� w WG21???
Jeden z tych trzech ludzi juďż˝ wyraziďż˝ swoje zdanie. Ja teďż˝ nie jestem
przekonany, �e to ma sens. Zw�aszcza, �e rozwi�zanie jest "nieczyste" z
punktu widzenia teorii (jakby C++ by�o z jakiego� punktu widzenia
czyste) i nie spe�nia regu�y "pogodzi� wszystkich". O ile to ostatnie
wydaje si� mo�liwe do przewalczenia (na zasadzie albo tyle albo mamy
powt�rk� ze standardu C++1x czyli "zn�w nie przejdzie") to pozostaje
"problem teorii". Choďż˝ ta teoria nie koniecznie przystaje do praktyki
(tzn. teoretycznie jest to brzydko, ale praktycznie nie ma znaczenia, ba
uwa�am, �e lekarstwo jest gorsze od choroby -- patrz moja dyskusja z
Qrczakiem w tym samym w�tku) to ma silne wsparcie w komitecie.
>
> Propozycja by�a jedna, Boehm & Spertus, je�eli uwa�asz �e by�o inaczej a
> nie by�e� na miejscu to nie wiem sk�d si� Twoja wiedza wzi�a.
Dlaczego imputujesz mi stwierdzenie, �e by�o kilka formalnych
propozycji? Ja tylko stwierdzi�em, �e propozycja nie wzi�a si� z
powietrza i �e godzi r�ne �yczenia i r�ne pomys�y.
> Je�eli przygotujesz lepsz� propozycj�, to mo�e ma ona jakie� szanse w
> kolejnej wersji standardu. Gotowy dokument mo�esz przes�a� do BS, on
> jest szefem EWG (Evolution Working Group) i podpowie co robiďż˝ dalej. Nie
> licz na zmian� w tym cyklu do C++0x , ale je�eli si� postarasz to masz
> szans� do nast�pnej wersji.
Oczywi�cie, �e w tej wersji nic si� nowego nie pojawi (nie ten etap).
Ba, nawet wyra�ne wykazanie popsucia dobrej propozycji (= default) nawet
si� ze zwyk�ym grzeczno�ciowym "sorry, to late" nie spotka�o. A kolejna
wersja to gdzieďż˝ po 2020 roku?
To zbyt odleg�y horyzont czasowy. W dodatku patrz�c po tym co wylecia�o
ze standardu, a nad czym wielu ludzi ci�ko pracowa�o odzywa si� moje
lenistwo -- po cholerďż˝ pracowaďż˝ nad czymďż˝ co i tak najprawdopodobniej
zostanie odrzucone. W dodatku z uwagi na horrendalnie d�ugi turnaround
(gorszy ni� w pa�stwowych programach kosmicznych, gorszy ni� przy
standaryzacji Fortranu, itd.; btw w programach kosmicznych zupe�nie
nieudane projejkty si� zamyka a nie na si�� kultywuje jak specyfikacje
wyj�tk�w) i brak sensownej korelacji "early feedback" z "final outcome"
prace mo�na kontynuowa� latami po to by trafi�a do kosz^h^h^h^hEWG.
Ca�o�� tylko utwierdza mnie w przekonaniu, �e "design by comitee" to
wyj�tkowo wymy�lny spos�b marnowania tw�rczej energii zar�wno cz�onk�w
komitetu jak i spo�eczno�ci. Jestem ciekaw czy po entuzjazmie w�r�d
"spo�eczno�ci C++" z lat 2003-2008 cokolwiek pozostanie, czy te� ludzie
pozabieraj� swoje zabawki i p�jd� do lepszej, bardziej obiecuj�cej
piaskownicy. A dla niewy�ytych w ulepszaniu j�zyk�w zaiste jest kilka
piaskownic du�o bardziej przyjaznych.
pzdr
Piotr Wyderski
> By� mo�e dlatego �e, po przesuni�ciu issue do etapu "Ready" brakuje
> ch�tnych �eby wraca� do pocz�tku.
W sprawie maila: nie, nie dosta�em �adnej odpowiedzi.
> Szkoda �e nie zauwa�y�e� tego problemu kilka mcy wcze�niej.
GCC-trunk miaďż˝ kilka krytycznych z mojego punktu widzenia
b��d�w, wi�c nie aktualizowa�em kompilatora. Przy okazji
wysz�o, �e "virtual ~C() = default;" generuje niewirtualny
destruktor, a potem tej konstrukcji w og�le zakazano.
BTW, dlaczego uwa�asz, �e obiekty podlegaj�ce GC
maj� by� niszczone w innym w�tku i dlaczego to jest
wada? Je�li obiekt mo�e by� w poprawny spos�b u�ywany
przez kilka w�tk�w, to nic nie stoi na przeszkodzie, by by�a
mo�liwo�� jego zniszczenia na dowolnym z nich. A je�li
chcesz, by niszczy� go w�tek-tw�rca, to te� s� sposoby
na zrobienie tego, np. poprzez zamro�enie w�tku, zmian�
warto�ci jego licznika rozkaz�w na procedur� od�miecania,
uruchomienie w�tku, ponowne zatrzymanie i wznowienie
w przerwanym miejscu. Sam u�ywam tu modeli kooperatywnych,
bo mam ju� infrastruktur� do tego, ale jak kto� chce przezroczysto�ci,
to te� mo�e j� dosta�.
Pozdrawiam
Piotr Wyderski
Sebastian Kaliszewski
> BTW, dlaczego uwa�asz, �e obiekty podlegaj�ce GC
> maj� by� niszczone w innym w�tku i dlaczego to jest
> wada? Je�li obiekt mo�e by� w poprawny spos�b u�ywany
> przez kilka w�tk�w, to nic nie stoi na przeszkodzie, by by�a
> mo�liwo�� jego zniszczenia na dowolnym z nich.
Te� tego nie rozumiem, wyrazi�em to niezrozumienie w pytaniu, czy Bronek
g�osowa� przeciw w�tkom...
> A je�li
> chcesz, by niszczy� go w�tek-tw�rca, to te� s� sposoby
> na zrobienie tego, np. poprzez zamro�enie w�tku, zmian�
> warto�ci jego licznika rozkaz�w na procedur� od�miecania,
> uruchomienie w�tku, ponowne zatrzymanie i wznowienie
> w przerwanym miejscu.
Qrczak wkleiďż˝ tu link do papieru m.in Hansa Boehma (tego od jego
w�asnego od�miecacza i od formalnej propozycji GC w C++1x) kt�ry to
papier wykazuje m.in jakie to straszna jest finalizacja (bro� Bo�e nie
niszczenie :) ) w tym samym w�tku. C� ja to, osobi�cie, traktuj� jako
Opowie�ci z Mchu i Paproci, bo problem po pierwsze g��wnie teoretyczny a
po drugie jest rozwi�zywalny �atwo bez mno�enia w�tk�w, ale przeczytaj
sam i swoje w�asne zdanie wyra� (jestem ciekaw).
Ale te�, skoro to ten sam pan Boehm, cz�onek komitetu zreszt�, to
przecie� nie zaprzeczy sam sobie. Wi�c proponowane GC w C++ nie mo�e
dzia�a� bez dodatkowego w�tku, itd...
pzdr
Bronek Kozicki
> Bronek Kozicki wrote:
>
>> By� mo�e dlatego �e, po przesuni�ciu issue do etapu "Ready" brakuje
>> ch�tnych �eby wraca� do pocz�tku.
>
> W sprawie maila: nie, nie dosta�em �adnej odpowiedzi.
wys�a�em Fw na Twoje konto @gmail.com (by�e� w Cc: wi�c my�la�em �e
dosta�e�).
B.
Bronek Kozicki
> Ba, nawet wyra�ne wykazanie popsucia dobrej propozycji (= default) nawet
> si� ze zwyk�ym grzeczno�ciowym "sorry, to late" nie spotka�o.
przeciwnie, spotka�o si� z opisaniem problem�w jakie zosta�y naprawione
przez tak� zmian�, oraz z pytaniem jaki konkretnie mia� po�ytek z mniej
restrykcyjnej wersji. Tyle �e Piotr, nie wiem czemu, tego nie otrzyma�
(by� w Cc:). Mam nadziej� �e dosta� mojego Fw. Prawd� m�wi�c, ja t�
odpowied� te� przeoczy�em i odszuka�em j� dopiero gdy przeczyta�em �e
Piotr nie dosta� �adnej odpowiedzi.
B.
Bronek Kozicki
> maj� by� niszczone w innym w�tku i dlaczego to jest
> wada?
w dyskusji o GC pojawia�y si� tylko takie propozycje kt�re uruchamiaj�
"finalizery" w w�tku nale��cym do GC.
Problemem najwi�kszym jest to �e "finalizery" nie dostarczaj� takich
samych gwarancji jak destruktory. Sebastian twierdzi �e GC mo�e
dostarczaďż˝ gwarancje nie gorsze niďż˝ deterministyczna destrukcja -
wcze�niej nie spotka�em si� z takim twierdzeniem. Zdecydowanie pomog�oby
to wprowadzeniu GC do C++ gdyby potrafiďż˝ to udowodniďż˝ i to nie mnie,
tylko WG21 - dzia�aj�cym rozszerzeniem j�zyka/bibliotek� itp. Bez tego
trudno to twierdzenie zweryfikowaďż˝, a komitet mocno siďż˝ oparzyďż˝ na
rozszerzeniach opartych o niezweryfikowane stwierdzenia (np export
template ...).
W�a�nie (wg koncepcji prezentowanych przez Boehm & Spertus) s�absze
gwarancje wykonania kodu przez GC by�y jego g��wnym problemem; drugim
byďż˝ koszt wykonania tego kodu.
B.
Bronek Kozicki
>> a nie by�e� na miejscu to nie wiem sk�d si� Twoja wiedza wzi�a.
>
> Dlaczego imputujesz mi stwierdzenie, �e by�o kilka formalnych
> propozycji? Ja tylko stwierdzi�em, �e propozycja nie wzi�a si� z
> powietrza i �e godzi r�ne �yczenia i r�ne pomys�y.
a to przepraszam, �le zrozumia�em Twoj� wypowied�.
> To zbyt odleg�y horyzont czasowy. W dodatku patrz�c po tym co wylecia�o
> ze standardu, a nad czym wielu ludzi ci�ko pracowa�o odzywa si� moje
> lenistwo -- po cholerďż˝ pracowaďż˝ nad czymďż˝ co i tak najprawdopodobniej
> zostanie odrzucone.
Chyba si� nie spodziewasz �e ci, kt�rym na GC nie zale�y (wliczaj�c w to
mnie) odwal� czarn� robot� za tych, kt�rzy chcieliby to mie�?
B.
Jacek Czerwinski
> On 30/12/2009 10:31, Piotr Wyderski wrote:
>
> w dyskusji o GC pojawia�y si� tylko takie propozycje kt�re uruchamiaj�
> "finalizery" w w�tku nale��cym do GC.
>
> Problemem najwi�kszym jest to �e "finalizery" nie dostarczaj� takich
> samych gwarancji jak destruktory. Sebastian twierdzi �e GC mo�e
> dostarczaďż˝ gwarancje nie gorsze niďż˝ deterministyczna destrukcja -
> wcze�niej nie spotka�em si� z takim twierdzeniem.
Kibicuj� w�tkowi, ale teraz zupe�nie inne pytanie bym zada�. Zaplecze
teoretyczne za naukami technicznymi (W tym programowanie - ale to samo
odno�nie wszystkich modeli wytrzyma�o�ci belki zginanej).
W teorii informatyki, widzďż˝ pewne, wcale nie takie ogromne obszary,
gdzie teoria czy to historycznie powsta�a wcze�niej, czy potrafi�a
wznie�� si� ponad dora�ne i 'produktowe' zagadnienia.
Do tych z dobr� dawk� og�lno�ci by�bym sk�onny zaliczy� teori�
relacyjnych baz danych, co� z sieci (��cznie z modelem OSI/ISO nie
maj�cym �adnej dok�adnej implementacji), sporo z numeryki i grafiki,
podstawowy przekaz OOP. Potem jednak id� takie teorie, kt�re s� zaledwie
bladym uog�lnieniem jednego przypadku (jednego maj�ce znaczenie
przemys�owe i kilku eksperyment�w jajog�owych).
�eby wr�ci� do w�tku, wydaje si� �e potraficie prowadzi� dyskurs
'wy�szo�� finalizer�w nad destruktorami jako takimi', na poziomie
og�lnym ...
Ja osobi�cie nie potrafi� zobaczy� og�lnego finalizera (znam takiego,
jakiego ma Java), ani og�lnego destruktora (cho� znam tego z C++).
Gdzie jest granica teoretycznego uog�nienia (wiem �e konieczne dlka
rozwoju) a doktoranckim biciem piany (jakim jest uog�nianie jednego
przypadku).
Sorry za oftop.
Sebastian Nibisz
> Chyba si� nie spodziewasz �e ci, kt�rym na GC nie zale�y (wliczaj�c w to
> mnie) odwal� czarn� robot� za tych, kt�rzy chcieliby to mie�?
Czyli wychodzi na to, �e jako takiej koncepcji rozwoju j�zyka C++ nie ma.
Kto� sie w og�le zajmuje jego rozwojem?
Pozdrawiam,
- Bastek -
Bronek Kozicki
(EWG) Evolution Working Group, kt�rego cz�onkowie oceniaj� propozycje
dostarczone do WG21. A czasami przygotowuj� w�asne, np. "nowe" auto i
initializer_list zosta�y zaproponowane przez BS.
B.
Paweł Kierski
[...]
> Stwierdzi�em 2 fakty:
> 1) �e gwarancji wywo�ania destruktora nie ma nie by�o i nie b�dzie
Mo�e ograniczmy si� do przypadk�w, gdzie nast�puje wyj�cie z zasi�gu
przed zako�czeniem programu. Bo o takie sytuacje chodzi w praktyce.
Reszta (statyczne obiekty i przypadki "awaryjne": abort, ostatni poziom
zwijania stosu przy nieobs�u�onym wyj�tku itp.) to albo dzia�anie
celowe, albo sytuacja, w kt�rej i tak niewiele da si� zrobi�,
a gwarancje zwalniania zasob�w spokojnie mo�na przerzuci� na system.
Inaczej brniecie w dyskusjďż˝, gdzie obie strony twardo broniďż˝ swoich
tez z nisko lataj�cymi kwantyfikatorami 8-)
> 2) �e GC mo�e dawa� nie s�absze gwaranacje ni� te co teraz s�.
Nadal s�abo wyobra�am sobie GC z gwarancj� tak�, jak destruktor w
sytuacji gwarantowanego opuszczania zasi�gu, ale pilnie �ledz� dalej...
--
Paweďż˝ Kierski
ne...@pkierski.net
Sebastian Nibisz
> Nadal s�abo wyobra�am sobie GC z gwarancj� tak�, jak destruktor w
> sytuacji gwarantowanego opuszczania zasi�gu, ale pilnie �ledz� dalej...
A ja nadal nie rozumiem w czym problem, bo skoro mo�na zagwarantowa�
zlokalizowanie porzuconego obiektu, to mo�na tak�e zagwarantowa� wykonanie
jego destruktora.
Pozdrawiam,
- Bastek -