Java-muisti malli

Java - muistimalli ( JMM ) kuvaa säikeiden käyttäytymistä Java - ajonaikaisessa ympäristössä .  Muistimalli on osa Java-kielen semantiikkaa ja kuvaa, mitä ohjelmoija voi ja ei saa odottaa kehittäessään ohjelmistoja ei tietylle Java-koneelle, vaan Javalle kokonaisuudessaan.

Alkuperäistä Java-muistimallia (johon sisältyy erityisesti "perkolokaalinen muisti"), joka kehitettiin vuonna 1995, pidetään epäonnistuneena: monia optimointeja ei voida tehdä menettämättä takuuta koodin turvallisuudesta. Erityisesti on olemassa useita vaihtoehtoja monisäikeisen " yksikätisen " kirjoittamiseen: [1]

• joko jokainen singletonin käyttö (vaikka objekti luotiin kauan sitten, eikä mikään voi muuttua) aiheuttaa säikeiden välisen lukon ;
• tai tietyissä olosuhteissa järjestelmä antaa keskeneräisen yksinäisen;
• tai tietyissä olosuhteissa järjestelmä luo kaksi yksinäistä;
• tai suunnittelu riippuu tietyn koneen käyttäytymisestä.

J2SE 5.0 (30. syyskuuta 2004) esitteli uuden Java-yhteisöprosessin kautta kehitetyn muistimallin nimeltä JSR-133 [2] [3] . Se kuvasti paremmin nykyaikaisten prosessorien ja kääntäjien toimintaa, ja muut kielet ovat ottaneet ideoita Java-mallista. Tärkeimmät panokset sen luomiseen antoivat Sarita Adwe , Jeremy Mason ja Bill Pugh 4] .

Tausta

Java - ohjelmointikielen avulla voit kirjoittaa monisäikeisiä ohjelmia. Koska Java voi toimia useissa erilaisissa prosessoreissa ja käyttöjärjestelmissä, säikeiden synkronointi on erityisen vaikeaa. Jotta ohjelmoija voisi tehdä joitain johtopäätöksiä ohjelmien käyttäytymisestä, Java-kehittäjät päättivät määritellä selkeästi kaikkien Java-ohjelmien erilaiset käyttäytymiset.

Nykyaikaisissa tietokoneissa koodia ei suoriteta siinä järjestyksessä, jossa se on kirjoitettu nopeuden vuoksi. Permutoinnin tekevät kääntäjä, prosessori ja muistialijärjestelmä. Moniprosessorikoneissa jokaisella ytimellä voi olla oma välimuisti , joka ei ole synkroninen päämuistin kanssa. Tämä tarkoittaa, että eri prosessoreilla voi olla eri arvoja samalle muuttujalle samanaikaisesti. Kun säikeet ovat paljon vuorovaikutuksessa toistensa kanssa, tämä ei yleensä ole toivottavaa: kestää paljon aikaa pysyä ajan tasalla siitä, mitä toinen prosessori on tehnyt.

Lisäksi yksisäikeisessä ympäristössä riittää, että järjestelmä vaatii "pseudosekvenssin" ohjelman suorittamista - tarkkailijalle, joka näkee vain I/O :n, näyttää siltä, ​​että kaikki toiminnot suoritetaan siinä järjestyksessä, jossa ne suoritetaan. ilmestyi ohjelmaan, vaikka ne eivät olisikaan. Kuitenkin jokainen, joka voi "katsoa" tietokoneen muistiin - mukaan lukien toinen lanka - kaikki nämä "temput" ovat havaittavissa. Tarkastellaan kahta säiettä, jotka suorittavat samanaikaisesti tällaista koodia ( xja yaluksi nollia).

Jos permutaatioita ei ole ja säiettä 2 luetaan y=2, se on taatusti x=1: kirjoitus kohteeseen xsuoritetaan ennen kirjoitusta y. Permutaatiolla näennäisen paradoksaalinen tilanne osoittautuu mahdolliseksi: r1=2, r2=0.

JMM sallii tämän monisäikeisten ohjelmien toiminnan, mutta kuvaa, milloin tällaiset permutaatiot ovat mahdollisia. Siten Java-muistimalli asettaa rajoituksia säikeiden vuorovaikutukselle, jotta mahdollisia optimointeja ei menetetä ja samalla monisäikeiset ohjelmat voisivat toimia luotettavasti ja ennustettavasti siellä, missä sitä tarvitaan. Ohjelmoija voi tehdä mitä tahansa päätelmiä siitä, missä järjestyksessä koodi suoritetaan monisäikeisessä koneessa, vaikka kääntäjän, prosessorin ja välimuistin tekemistä optimoinneista huolimatta.

Muistimalli

Sääntö 1: Yksisäikeiset ohjelmat toimivat näennäisperäkkäin. Tämä tarkoittaa: todellisuudessa prosessori voi suorittaa useita operaatioita kelloa kohden muuttaen samalla niiden järjestystä, mutta kaikki tietoriippuvuudet säilyvät, joten käyttäytyminen ei eroa peräkkäisestä.

Sääntö numero 2: ei ole tyhjästä-arvoja. Minkä tahansa muuttujan lukeminen (paitsi ei- volatile longja double, joille tämä sääntö ei välttämättä ole tosi) palauttaa joko oletusarvon (nollan) tai jotain, joka on kirjoitettu sinne toisella komennolla.

Ja sääntö numero 3: loput tapahtumat suoritetaan järjestyksessä, jos niitä yhdistää tiukka osajärjestyssuhde "suoritetaan ennen" ( englanniksi  happens before ).

"Suorita ennen"

"Tapahtuu ennen" ( englanniksi  happens before ) on Leslie Lamportin keksimä tiukka osajärjestyssuhde (antireflexiivinen, antisymmetrinen, transitiivinen), joka on otettu käyttöön atomikomentojen ( ++eikä atomin) välillä . Se tarkoittaa, että toinen joukkue on "tietoinen" ensimmäisen tekemistä muutoksista. --

Erityisesti yksi suoritetaan ennen toista tällaisia ​​operaatioita varten (luettelo ei ole tyhjentävä):

• Synkronointi ja monitorit :
  • Monitorin sieppaus (alku synchronized, menetelmä lock) ja kaikki sen jälkeen samassa säikeessä.
  • Näytön ( end synchronized, method unlock) ja kaiken sitä edeltävän palauttaminen samaan ketjuun.
    • Siten optimoija voi työntää rivejä synkronointilohkoon, mutta ei ulos.
  • Näytön palauttaminen ja sen sieppaaminen toisella langalla.
• Kirjoittaminen ja lukeminen:
  • Kaikki datariippuvuudet (eli kirjoittaminen mihin tahansa muuttujaan ja sen lukeminen) yhdessä säikeessä.
  • Kaikki samassa virrassa ennen volatile-muuttujaan kirjoittamista ja itse kirjoitus.
  • volatile-lukeminen ja kaikki sen jälkeen samassa virrassa.
  • Kirjoittaminen volatile-muuttujaan ja sen lukeminen [2] [5] . Siten volatile-write tekee muistille sen, mitä monitorin palautus tekee, ja luku tekee sen, mitä kaappaus [6] . Tämä tarkoittaa: jos yksi säie on kirjoittanut volatile-muuttujaan ja toinen on havainnut sen, kaikki kirjoitusta edeltävä suoritetaan ennen kaikkea lukemisen jälkeen tulevaa; katso kuva.
    • Objektimuuttujien (esimerkiksi volatile List x;) osalta tällaiset vahvat takuut pätevät objektiviittaukselle, mutta eivät sen sisällölle.
• Kohteen huolto:
  • Staattinen alustus ja kaikki toiminnot objektien esiintymien kanssa.
  • Kirjoittaminen final-kenttiin konstruktorissa [7] ja kaikki konstruktorin jälkeen. Poikkeuksena yleiseen transitiivisuuteen tämä tapahtuu ennen kuin relaatio ei liity transitiivisesti muihin sääntöihin ja voi siksi aiheuttaa ristiriitaa [8] .
  • Kaikki työt esineen ja finalize().
• Suoratoistopalvelu:
  • Säikeen aloittaminen ja mikä tahansa ketjussa oleva koodi.
  • Säikeeseen liittyvät nollausmuuttujat ja kaikki säikeen koodit.
  • Koodi virrassa ja join(); koodi virrassa ja isAlive() == false.
  • interrupt()virtauksen ja pysäytyksen havaitseminen.

Vaikuttaa

Monisäikeisten ja rinnakkaisten järjestelmien laajan käyttöönoton vuoksi tarvittiin työkalupakki, jossa oli selkeä semantiikka. Java-muistimalli oli ensimmäinen yritys kehittää kattava säikeiden välinen viestintämalli suurelle ohjelmointikielelle [9] .

C++03 : ssa ainoa huomautus monisäikeisyydestä on, että volatile-muuttujilla ei ole pääsynopeuksien optimointeja. Tämä ei myöskään riittänyt käyttämään uudelleenjärjestävän kääntäjän/prosessorin koko tehoa eikä saamaan virhettä, joka liittyy jonkin komennon epäjärjestyksessä suoritukseen. Samanlainen muistimalli sisältyi C++11 :een [10] .

Katso myös

• Muistimalli
• Muistimalli Intel x86
• Muistimalli C-kielellä

Muistiinpanot

1. ↑ "Kaksoistarkistettu lukitus on rikki" -ilmoitus . Haettu 21. heinäkuuta 2013. Arkistoitu alkuperäisestä 6. maaliskuuta 2012. (määrätön)
2. ↑ 1 2 Goetz, Brian Java-muistimallin korjaaminen, osa 2 (downlink) (24. helmikuuta 2004). Haettu 18. lokakuuta 2010. Arkistoitu alkuperäisestä 8. tammikuuta 2007. (määrätön) 
3. ↑ Jeremy Manson ja Brian Goetz. JSR 133 (Java-muistimalli) UKK (helmikuu 2004). — « Java-muistimalli kuvaa, mikä käyttäytyminen on laillista monisäikeisessä koodissa ja kuinka säikeet voivat olla vuorovaikutuksessa muistin kautta. Se kuvaa ohjelman muuttujien välistä suhdetta ja matalan tason yksityiskohtia niiden tallentamisesta ja hakemisesta muistiin tai rekistereihin todellisessa tietokonejärjestelmässä. Se tekee tämän tavalla, joka voidaan toteuttaa oikein käyttämällä monenlaista laitteistoa ja monenlaisia ​​kääntäjien optimointeja. ". Käyttöpäivä: 18. lokakuuta 2010. Arkistoitu alkuperäisestä 4. syyskuuta 2013. (määrätön)
4. ↑ James Gosling, Bill Joy, Guy L. Jr. Steele, Gilad Bracha, Alex Buckley. Java Language Specification, Java SE 7 Edition. - Pearson Education, 2013. - ISBN 978-0-13-326032-8 .
5. ↑ Synkronointi ja Java-muistimalli . Haettu 21. heinäkuuta 2013. Arkistoitu alkuperäisestä 11. toukokuuta 2013. (määrätön)
6. ↑ JSR-133-keittokirja (downlink) . Haettu 18. heinäkuuta 2013. Arkistoitu alkuperäisestä 25. syyskuuta 2013. (määrätön) 
7. ↑ Missään, paitsi konstruktorissa, finalet voi kirjoittaa -kenttiin.
8. ↑ >työhuomautuksia: Takuu viimeisille kentille . Haettu 22. heinäkuuta 2013. Arkistoitu alkuperäisestä 16. tammikuuta 2015. (määrätön)
9. ↑ Goetz, Brian Java-muistimallin korjaaminen, osa 1 (downlink) (24. helmikuuta 2004). Haettu 17. helmikuuta 2008. Arkistoitu alkuperäisestä 13. elokuuta 2009. (määrätön) 
10. ↑ Boehm, Hans Säikeet ja muistimalli C++:lle (downlink) . Käyttöpäivä: 17. helmikuuta 2008. Arkistoitu alkuperäisestä 4. syyskuuta 2013. (määrätön) 

Linkit

• Java teoria ja käytäntö: Java-muistimallin korjaaminen, osa 1 Arkistoitu alkuperäisestä 13. elokuuta 2009.  — Artikkeli, joka kuvaa alkuperäisen Java-muistimallin ongelmia.
• Java teoria ja käytäntö: Java-muistimallin korjaaminen, osa 2 Arkistoitu alkuperäisestä 8. tammikuuta 2007.  — Selittää muutokset, jotka JSR 133 on tehnyt Java-muistimalliin.
• Java-muistimalli linkit
•  JSR- 133 -verkkosivu
•  JSR- 133 UKK
• JSR-133 FAQ:n käännös  (venäjä)
• JSR-133 käyttöönottoopas