Libi se mi, ze neodbihate od tematu :o). Tak naposledy (protoze tato "diskuze" v konferenci pravdepodobne temer nikoho nezajima):
>>>> Jak muze jine vlakno ziskat odkaz na takto vytvoreny objekt drive nez dojde >>>> k navratu z new? (Krome zminene moznosti predani odkazu v konstruktoru >>>> Tridy). >>>> >>>> Mohl bys naznacit jak to bude vypadat v kodu? >>>> >>>> >>> Uvedu tedy kod primo ze specifikace: >>> >>> http://java.sun.com/docs/books/jls/third_edition/html/memory.html#66562 >>> >>> class FinalFieldExample { >>> final int x; >>> int y; >>> static FinalFieldExample f; >>> public FinalFieldExample() { >>> x = 3; >>> y = 4; >>> } >>> static void writer() { >>> f = new FinalFieldExample(); >>> } >>> static void reader() { >>> if (f != null) { >>> int i = f.x; // guaranteed to see 3 >>> int j = f.y; // could see 0 >>> } >>> } >>> } >>> >> >> Hmm. Hezke. To ovsem neni ani nahodou odpoved na moji otazku "Jak muze vlakno >> ziskat odkaz na objekt vytvareny v jinem vlakne drive nez dojde k navratu z >> new". >> > Proc by nemohlo? JIT si to muze prehazet jak chce kdyz dodrzi vlastnosti > pameti dane specifikaci. > Vyse uvedeny kod muze JIT serializovat napriklad takto: > > vlakno1 vlakno2 > writer(); > x=3; > f= to co casem vrati new ve vlakne 1 je > zapsano nejdriv do pameti pro vlakno 2 > f!=null; // je true > // tady JIT vi, ze muze klidne pustit vlakno 2, i kdyz vlakno 1 jeste si > do sve pameti pro f nic nezapsalo > int i=f.x; // cteme 3 > int j=f.y // cteme 0 > y=4; > f= zapiseme f pro vlakno 1 > ..... Jak bude vypadat JAVOVSKY kod vlaken 1 a 2? Jinak v jednom z predchozich mailu jsem Vam doporucoval seznamit se s Initialization safety. Protoze moje rada patrne nebyla vyslysena, pridavam citaci z http://www.ibm.com/developerworks/library/j-jtp03304/: "The new JMM also seeks to provide a new guarantee of initialization safety -- that as long as an object is properly constructed (meaning that a reference to the object is not published before the constructor has completed), then all threads will see the values for its final fields that were set in its constructor, regardless of whether or not synchronization is used to pass the reference from one thread to another. Further, any variables that can be reached through a final field of a properly constructed object, such as fields of an object referenced by a final field, are also guaranteed to be visible to other threads as well. This means that if a final field contains a reference to, say, a LinkedList, in addition to the correct value of the reference being visible to other threads, also the contents of that LinkedList at construction time would be visible to other threads without synchronization. The result is a significant strengthening of the meaning of final -- that final fields can be safely accessed without synchronization, and that compilers can assume that final fields will not change and can therefore optimize away multiple fetches." Tim je doufam jasne, ze ten Vas pseudokod vyse je nerealny. Z.T. -- Zdenek Tronicek Department of Computer Science and Engineering Prague tel: +420 2 2435 7410 http://cs.felk.cvut.cz/~tronicek Quoting Lukas Barton <[EMAIL PROTECTED]>: > Zdeněk Troníček wrote: > > Ja jsem ten kod uvadel proto, aby bylo videt, ze ten Vas scenar neni mozny. > > Odkaz na alokovanou pamet je na zasobniku a ten je privatni pro dane > vlakno. > > > Asi se nedomluvime ;-) > > Prostudujte si nasledujici odkazy: > > http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html > > Tam mate kod, ktery vygeneruje JIT (nikoliv bytecode, ktery posilate vy). > > Potom porovnejte > http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.5 > a http://java.sun.com/docs/books/jls/first_edition/html/12.doc.html#44670 > (jsou stejne - v obou je Just before a reference to the newly created > object is returned as the result, the indicated constructor is processed > to initialize the new object using the following procedure:.....) > > Ale kdyby platilo, to co tvrdite, muselo by to s volatile fungovat uz v > 1.4 - spravny pointer byste dostal, ale videl byste neinicializovanou > pamet. Coz neni pravda (viz prvni odkaz): > > "This /does not work/ under the current semantics for volatile." > > Protoze v 1.4 a driv mohl dat JIT instrukce konstruktoru az zapis do > volatile promenne a taky to delal ;-). > > > > Jinak kdyz jste zabrousil k izolacnim urovnim, tak si neodpustim poznamku. > > Izolacni urovne byly definovany v SQL'89 "specifikaci", tj. tim, jak > ovlivnuji > > pohled klienta na databazi. Jak se ovsem brzy ukazalo, definice to nebyla > moc > > presna a pro pochopeni toho, jak skutecne funguji, je temer nezbytne > seznamit > > se s implementaci pomoci zamku (ackoliv nekdo muze namitnout, ze > implementovany > > mohou byt i jinak - a bude mit pravdu). > > > To muzeme nechat na priste. Taky do toho vidim. A taky se muzeme > nedohodnout. > (vim jak to ma implementovane Informix, Oracle, DB2, MS SQL Server > 2003/2005 a Interbase). > > Z.T. > > > >
