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

• #13014 dqdb nagyúr jattila48 #13011

  Új Válasz 2019-06-14 12:46:08 #13014

  Ú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

  

  dqdb

  nagyúr

  válasz jattila48 #13011 üzenetére

  A Windows ReplaceFile API függvényével kapcsolatban érdekelne, hogy az mennyiben tekinthető atomi műveletnek.
  Ha átadsz backup fájlnevet, akkor a hívó szempontjából közel atominak tekinthető. A közel szó arra vonatkozik, hogy az eredeti fájl tartalma megmarad, csak az attribútumai nem (részletek itt).

  A kérdésem az, hogy a Windows preemptív ütemezője átadhatja-e a vezérlést másik thread-nek/processznek a ReplaceFile végrehajtása közben.
  Természetesen. És mivel jellemzően egyetlen szálnál több létezik manapság egy processzorban, így még a preemptív végrehajtásfelfüggesztés sem kell ahhoz, hogy párhuzamosan más is fusson.

  Mert az, hogy a ReplaceFile teljesen vagy egyáltalán nem hajtódik végre, rendben van, de előfordulhat-e, hogy a ReplaceFile véhrehajtása közben egy másik thread megpróbálja megnyitni a helyettesítendő file-t?
  Előfordulhat.

  Ekkor ugyanis lehet, hogy a másik thread nem fogja tudni megnyitni a file-t.
  Ha olyan sharing flagekkel nyitja meg, amit a ReplaceFile nem enged, akkor nem fog sikerülni, ha olyannal, hogy engedi, akkor igen.

  Ha a ReplaceFile olyan értelemben lenne atomi, hogy az ütemező közben nem adhatná át a vezérlést másik thread-nek, akkor ez a probléma nem léphetne fel.
  Vagyis egy ReplaceFile hívás blokkolná a teljes operációs rendszert arra az időre, ami nyilvánvalóan nagyon nem jó.

  TxF kell neked, és ott a MoveFileTransacted hívást, aminél minden fél számára atomi művelet a mozgatás. Vagy gondold át a választott megoldást, mert a legtöbb esetben más működést választva eliminálhatóak azok az esetek, amelyekre most választ keresel.

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