Új hozzászólás Aktív témák

• #10019 skoda12 aktív tag Dinter #10018

  Új Válasz 2018-10-24 22:29:33 #10019

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  skoda12

  aktív tag

  LOGOUT blog (1)

  válasz Dinter #10018 üzenetére

  Itt több esetet kell majd szétválogatni szerintem. Induljunk egy runnable állapotból, ekkor a lépések:

  1. A foobar.wait() hívása előtt meg kell szerezni a monitor lockját. Ez vagy sikerül elsőre vagy blocked állapotba kerül a thread, ha valaki másnál van lock.
  2. Valahogy túljutunk az előző ponton, runnable állapotban van a thread és meghívódik a foobar.wait(). Az új állapot waiting.
  3. Valamiért (*) felébred a thread, runnable állapotba kerül. Ahhoz, hogy ki tudjon lépni a wait()-ből kell a monitor lock. Itt megint vagy sikerül elsőre vagy blocked állapot jön és ha megvan a lock akkor runnable megint.

  (*) A notify() hatására átmehet blocked állapotba a thread. A foobar.notify() híváshoz is kell a monitor lock. Ha a felébresztett thread már futna, de a notify()-t hívó thread még fogja a lockot, akkor a felébresztett thread megy a blocked állapotba. Ha viszont véletlen úgy kapna cpu időt, hogy a notfiy()-t hívó thread (és mindenki más) már eleresztette a lockot, akkor ki is maradhat ez a blocked állapot.
  Viszont nem csak a notify() miatt mehet át ilyen állapotokon a thread. Például spurious wakeup miatt a wait()-et hívó thread még a notify() hívás előtt is felébredhet "magától". És akkor itt megint jön az, hogy vagy runnable vagy runnable + blocked + runnable állapotokon megy át.

Új hozzászólás Aktív témák