A Sun az RDBMS-ekből ellesett módszerhez hasonló memória lock-olási mechanizmuson dolgozik

Címkék

A Sun azon dolgozik, hogy a multithreading támogatását kiegészítse annak érdekében, hogy egy adott thread által lezárt memóriaterületet másik thread(-ek) ne tudj(anak)on felülírni. Az eljárást tranzakcionális memóriának hívják. A tranzakcionális memória támogatás megoldható hardveresen és szoftveresen is. A Sun egy hibrid megoldást készít. A támogatás a Rock processzorban lesz hardveresen implementálva. A Solaris operációs rendszer már most kínál lehetőséget a szolgáltatás kiaknázására, így az alkalmazásfejlesztők már nekiállhatnak alkalmazásokat írni rá. Ha megjelenik a Rock, a hardveres támogatásból adódóan a teljesítmény jelentősen nőni fog. Bővebben a dologról itt illetve a Sun kutatási oldalán a Transactional Memory cikkben. A szoftveres megoldás hátulütőiről a Understanding Tradeoffs in Software Transactional Memory dokumentum szolgáltathat infókat.

Hozzászólások

Érdekes gondolat. A Fortress után ez már a második kezdeményezésük, ami a szoftverek párhuzamosítását célozza. Annak ellenére, hogy a processzorok órajelei már jó ideje nem növekednek az elvárt ütemben mások még nem hype-olják ennyire a párhuzamosítást.

Hallottam olyat, hogy régebben már volt egyszer úgy(akkor még nem követtem az eseményeket, de kb a kilencvenes évek elején lehetett), hogy az észnélküli sebességnövelés lassulni fog. Akkor végül nem következett ez be. Most vajon be fog következni tényleg?

Az Intel hetente küldözget mindenféle seminarokról, meg webcastokról, doksikról, és hasonlókról linkeket, amelyek kifejezetten a többszálú környezetben való hatékony programozásról szólnak. Szóval nyomja más is keményen, az Intelnek ez most elég fontos, bár igaz, hogy ők talán jobb helyzetben vannak a kevesebb, de gyorsabb maggal...

Hm, ilyet utoljára a VAX+VMS párosról tudtam, hogy az oprendszerhez kalapálják hozzá a proci újabb verzióit. :)

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

a "designed for vista" az mire utal?:) m$ kornyeken csinaljak amit karnak oszt te vegyel ujjabb hardwaret ha akarod (maxon) hasznalni..
a linux miert szupportal csomo mindent alapbol?? mert ok a hardwarre irjak a cuccost nem forditva, ha jo latom. s winbe meg teheted fel a cdnyi drivereket, arrol nem is besz h fel se tudod rakni ha nincs sata-driveres floppy-d (ha jol tudom, persze az eredeti windowst)

marketing.

amúgy a 'Linux csomó mindent szupportál alapból' -dolog sántít azért. Elég kevés gyártó van (sajnos) aki odaadja a speckót, neadjisten! drivert ír. Inkább arról van szó hogy ha 2-3 fejlesztőnek van valami cucca akkor ők írnak rá valami driverféleséget, amit adott esetben felkap a közösség, ha nem akkor marad a google.

Nagyon pontatlan a cikk cime es bevezetoje. A tranzakcionalis memoria a lock alapu modszerek _kivaltasara_ szuletett. Igy a rendszer az ido nagy reszet nem lockokra torteno varakozassal tolti, hanem az osszefogott muveleteket (gyak.: amit eddig a lock es unlock kozott volt) szetbontva, atrendezve, a fuggosegek kezelesevel, ekvivalens modon vegrehajtja.

A mokas az, hogy a Java Write Once Run Anywhere modellje is okozhat komoly meglepeteseket tobbprocesszoros/tobbszalu mukodesnel kulonbozo gepeken, mert a futtato JVM implementacioja fugg a processzor architecturatol es processzor/memoria konzisztenciamodelltol (pl: a java spec konzisztencia modellje megenged bizonyos muveleteket, de ezeknel szigorubb a futtato processzor architectura, igy gyakorlatban nem fordul elo, viszont mas architecturan kiprobalva mar elofordulhat!).

Annyi van benne, amit a Sun Gives Multithreading an RDBMS Feel cikkből ki lehetett hámozni. Amennyiben írsz egy pontos összfoglalót a témában, azt szívesen kiteszem. Engem érdekelne - hiszen ahogy a Sun doksi írja a tranzakcionális memória a még a legtöbb fejlesztő számára is ismeretlen fogalom -, de azt hiszem másokat is. Szóval hajrá, én támogatom :)

--
trey @ gépház