UNIX + move gleichzeitig möglich

[romy]

Hi ihr Lieben,

ich hätte mal ein Frage an die Unix/Linux-Experten.
Wenn 2 Skripte gleichzeitig folgenden Befehl ausführen würden:

mv blubber blubber1
[1]

gewinnt dann ein Skript und das andere bekommt immer ein cannot access denied oder ist es möglich, dass beide scheinbar gewinnen und keinem Skript ein cannot access mitgeteilt wird? Wenn man diese nacheinander ausführt, bekommt das 2. Skript ein cannot access zurück und der move schlägt logischerweise fehl, da blubber ja nicht mehr da ist.

Zugegeben eine sehr hypothetische Frage ;) Mich würde dies interessieren, da ich gerade auf Fehlersuche bin und ich eine solche Stelle als Ursache gefunden habe, aber mir keiner glaubt, da es wohl unmöglich ist, dass dies passiert.

Vielen Dank!

[1] blubber und blubber1 sind jetzt mal Dateien.

ciao
romy

[Hamstar]

Zugegeben eine sehr hypothetische Frage ;)

Ich riskiere mal eine Antwort: Da verschiedene Prozesse gleichzeitig versuchen könnten auf eine Datei zuzugreifen und diese umzubenennen und da das Betriebssystem keine Priorisierung diesbzgl. vornehmen kann (wohl bzgl. der Zuweisung der CPU-Zeit, aber nicht bzgl. der Ausführung einer einzelnen (Unter-)Aufgabe) kann rein logisch betrachtet nicht vorhergesehen werden welcher Prozess zuerst diese Datei-Umbenennung vornehmen wird.

[romy]

Hi Hamstar,

Ich riskiere mal eine Antwort: Da verschiedene Prozesse gleichzeitig versuchen könnten auf eine Datei zuzugreifen und diese umzubenennen und da das Betriebssystem keine Priorisierung diesbzgl. vornehmen kann (wohl bzgl. der Zuweisung der CPU-Zeit, aber nicht bzgl. der Ausführung einer einzelnen (Unter-)Aufgabe) kann rein logisch betrachtet nicht vorhergesehen werden welcher Prozess zuerst diese Datei-Umbenennung vornehmen wird.

Das ist auch i.O., es ist quasi egal, wer umbenennt, interessant ist, ob beide umbenennen können, ohne dass einer der beiden Prozesse einen Fehler bekommt.

Ich wühle ja immer ungern in anderer Leute Skripte ;)
Ich versuche mal darzustellen, was passiert.

Es kann ein Skript a mehrfach laufen. Um ein gleichzeitige Zugreifen auf bestimmte Dateien zu unterbinden, wird zum Prozessbeginn eine Datei umbenannt und nach Prozessende wieder rückumbenannt. Jeder der gleichzeitig laufenden Prozesse prüft vorher, ob er die Umbenennung vornehmen kann, wenn nein, geht er in eine Warteschleife, wenn ja gehts los. In der Warteschleife wird solange geguckt ob die Datei umbenannt werden kann bis es klappt, dann springt der Prozess raus.

Das ist sehr unsauber, da dadurch ggf. das Initiativskript nicht mehr das bearbeitet, weswegen es angesprungen ist, wie du schon sagtest. Das ist aber egal an der Stelle hauptsache es gibt genausoviele Dinge zu tun, wie auch Prozesse laufen.

Jetzt tritt aber hin-und wieder das Phänomen auf, dass doch zwei  Prozesse gleichzeitig arbeiten, das dürfte ja eigentlich nicht sein.
Ich meine aber schon.

Ist mein Anliegen jetzt deutlicher? Ich weiß noch nicht so genau, wie ich es umschreiben soll.

Vielen Dank.

ciao
romy

[Hamstar]

Das ist auch i.O., es ist quasi egal, wer umbenennt, interessant ist, ob beide umbenennen können, ohne dass einer der beiden Prozesse einen Fehler bekommt.

Dir geht es also eigentlich gar nicht um das Verhalten der Prozesse sondern um das Verhalten des file systems.

OK, da riskiere ich auch mal wieder eine Aussage:   ;)
Es ist technisch möglich das file system so zu gestalten, dass Konfliktfälle entweder nicht entstehen oder zumindest automatisch so wie von Dir erwartet bearbeitet werden, also kein Gekäbbel.
Und da das technisch möglich ist, wird das file system auch (der UNIX-Philosophie folgend - http://de.wikipedia.org/wiki/Unix-Philosophie) dementsprechend angelegt sein.

[romy]

Hi Hamstar,

OK, da riskiere ich auch mal wieder eine Aussage:   ;)
Es ist technisch möglich das file system so zu gestalten, dass Konfliktfälle entweder nicht entstehen oder zumindest automatisch so wie von Dir erwartet bearbeitet werden, also kein Gekäbbel.
Und da das technisch möglich ist, wird das file system auch (der UNIX-Philosophie folgend - http://de.wikipedia.org/wiki/Unix-Philosophie) dementsprechend angelegt sein.

Puh, jetzt hast du mich abgehängt, ich kann deinen Ausführungen nicht ganz folgen. Ich habe mal auf der verlinkten Seite geblättert und würde jetzt deine Aussage so verstehen, dass wenn zwei Prozesse das Gleiche wollen immer eines den Vorang bekommt um Konflikfrei zu laufen!? Habe ich das jetzt richtig verstanden?

ciao
romy

[Hamstar]

Puh, jetzt hast du mich abgehängt, ich kann deinen Ausführungen nicht ganz folgen. Ich habe mal auf der verlinkten Seite geblättert und würde jetzt deine Aussage so verstehen, dass wenn zwei Prozesse das Gleiche wollen immer eines den Vorang bekommt um Konflikfrei zu laufen!? Habe ich das jetzt richtig verstanden?

Ich hatte mich unklar ausgedrückt. Dich interessieren m.E. nicht die Prozesse sondern die Beschaffenheit des Dateisystems. Die Frage lautet: Verhält sich das Dateisystem so, dass es Anforderungen in einer Form abarbeitet, die man als sequentiell bezeichnen könnte zumindest als konfliktfrei. Ein Konflikt wäre zum Beispiel gegeben, wenn zwei Prozesse versuchen ein und dieselbe Datei anders zu benennen und das Dateisystem beiden meldet "OK", aber es dennoch nur eine Aktion ausgeführt hat oder wenn es einen inkonsistenten Zustand erlangt, in anderen Worten "Die Datei ist weg.".

Thompson, der auch in dem Gebiet einen Namen hat in dem ich früher meine Hauptkompetenzen hatte, dürfte sich der oben beschriebenen Problematik bewusst gewesen sein und die Sache adäquat bearbeitet haben. Kurzum: Die von Dir ins Auge gefasste Fehlerquelle schliesse ich aus. (Nichtsdestotrotz könntest Du mal die Bug-List des von Dir analysierten UNIX durchgehen. Muss aber nicht sein. ;)

(Übrigens ist Deine Frage (zumindest füpr mich ;) interessant, denn eigentlich interessiert Dich auch die Frage, ob Software deterministisch funktioniert. Ich meine, dass Betriebssysteme inkl. Dateisysteme so funktieren müssen (also transaktional). Werden allerdings Prozesse ausgeführt, dann ist nicht mehr vorhersehbar, welcher Prozess "gewinnt". In dieser Schicht funktioniert Software also nicht mehr deterministisch. (Wobei Physiker da durchaus eine andere, eine esoterische, Meinung pflegen könnten. ; ))

[Hamstar]

Was die von Dir analysierten Stapel natürlich machen sollten sind die Rückgabewerte des "move" ("mv") auszuwerten. Geschieht das nicht, dann hättest Du den Bug.   :)

[Der Martin]

Hi Romy,

ich hätte mal ein Frage an die Unix/Linux-Experten.

bin ich nicht - aber mit den Grundlagen von Betriebssystemen im allgemeinen kenn' ich mich ein bissl aus. :-)

Wenn 2 Skripte gleichzeitig folgenden Befehl ausführen würden:
mv blubber blubber1
gewinnt dann ein Skript und das andere bekommt immer ein cannot access denied oder ist es möglich, dass beide scheinbar gewinnen und keinem Skript ein cannot access mitgeteilt wird?

Was meinst du mit "cannot access denied"? ;-)

Nehmen wir mal zwei verschiedene Szenarien.

1. Einprozessorsystem
Eine echte Gleichzeitigkeit verschiedener Prozesse gibt's hier nicht. Stattdessen springt die CPU in schneller Folge zwischen den aktiven Prozessen hin und her, so dass der Eindruck von gleichzeitiger Ausführung entsteht. Aber in jedem Fall ist eindeutig *eins* der beiden Scripte das erste, das die Anforderung "move/rename" ans Betriebssystem absetzt.
Kommt die Anforderung des zweiten Scripts nun, bevor das Umbenennen abgeschlossen ist, wird dieses zweite Script vermutlich schon ein "file not found" bekommen.

2. Mehrprozessorsystem
Hat ein Rechner mehrere CPUs, die unabhängig voneinander verschiedene Prozesse bearbeiten können, dann ist auch echte Gleichzeitigkeit möglich. Eine Kollision gleichzeitig eintreffender move/rename-Anforderungen ist daher vorstellbar; es liegt aber in der Verantwortung des Betriebssystems, diese Kollision sinnvoll zu handeln und einem der beiden Prozesse den Vorzug zu geben. Das Ergebnis dürfte dann aber dasselbe sein wie beim Einprozessorsystem.

Zugegeben eine sehr hypothetische Frage ;)

Eigentlich nicht. Okay, der konstruierte Fall der (Quasi-)Gleichzeitigkeit ist unwahrscheinlich. Aber genau solche Konfliktsituationen müssen beim Design eines Betriebssystems durchaus berücksichtigt werden.

Mich würde dies interessieren, da ich gerade auf Fehlersuche bin und ich eine solche Stelle als Ursache gefunden habe, aber mir keiner glaubt, da es wohl unmöglich ist, dass dies passiert.

Da kann ich jetzt nichts dazu sagen, solange ich die näheren Umstände nicht kenne.

So long,
 Martin

[romy]

Hi Martin,

Was meinst du mit "cannot access denied"? ;-)

cop&paste-Fehler ;)

1. Einprozessorsystem
   Eine echte Gleichzeitigkeit verschiedener Prozesse gibt's hier nicht. Stattdessen springt die CPU in schneller Folge zwischen den aktiven Prozessen hin und her, so dass der Eindruck von gleichzeitiger Ausführung entsteht. Aber in jedem Fall ist eindeutig *eins* der beiden Scripte das erste, das die Anforderung "move/rename" ans Betriebssystem absetzt.
   Kommt die Anforderung des zweiten Scripts nun, bevor das Umbenennen abgeschlossen ist, wird dieses zweite Script vermutlich schon ein "file not found" bekommen.

2. Mehrprozessorsystem
   Hat ein Rechner mehrere CPUs, die unabhängig voneinander verschiedene Prozesse bearbeiten können, dann ist auch echte Gleichzeitigkeit möglich. Eine Kollision gleichzeitig eintreffender move/rename-Anforderungen ist daher vorstellbar; es liegt aber in der Verantwortung des Betriebssystems, diese Kollision sinnvoll zu handeln und einem der beiden Prozesse den Vorzug zu geben. Das Ergebnis dürfte dann aber dasselbe sein wie beim Einprozessorsystem.

Danke, das war sehr aufschlussreich.

Mich würde dies interessieren, da ich gerade auf Fehlersuche bin und ich eine solche Stelle als Ursache gefunden habe, aber mir keiner glaubt, da es wohl unmöglich ist, dass dies passiert.
Da kann ich jetzt nichts dazu sagen, solange ich die näheren Umstände nicht kenne.

Es handelt sich um ein HPUX-System mit mehreren Prozessoren.
Mir ging es ja nur um die potientielle Möglichkeit, da mir gesagt wurde "Das kann nicht sein, da geht nie". Ich bin da immer etwas vorsichtiger, auch wenn der Prozentsatz gering sein mag, wenn es gehen könnte, dass ist jetzt auch das, was ich mitgenommen habe: Bei einem System mit mehreren Prozessoren ist es möglich, wenn das Betriebssystem den Fall nicht ordentlich ausschliesst!?

ciao
romy

[Der Martin]

Hallo,

Was meinst du mit "cannot access denied"? ;-)
cop&paste-Fehler ;)

einen Polizisten geleimt? Na, du bist mir eine ...  *scnr*

Da kann ich jetzt nichts dazu sagen, solange ich die näheren Umstände nicht kenne.
Es handelt sich um ein HPUX-System mit mehreren Prozessoren.
Mir ging es ja nur um die potientielle Möglichkeit, da mir gesagt wurde "Das kann nicht sein, da geht nie".

Für die Realisierung eines beliebigen Systems würde ich nicht meine Hand ins Feuer legen wollen, aber zumindest der Theorie nach DARF das nicht sein. Und Unix und seine Derivate haben eine so lange Evolution hinter sich, dass solche vergleichsweise banalen Probleme eigentlich keine Probleme mehr sein dürften.

Ich bin da immer etwas vorsichtiger, ...

Das ist auch gut so. Eine gesunde Skepsis und das Hinterfragen von Dingen, die man sonst als selbstverständlich hinnimmt, finde ich gut.

Bei einem System mit mehreren Prozessoren ist es möglich, wenn das Betriebssystem den Fall nicht ordentlich ausschliesst!?

So sehe ich das, ja. Die Hardware ermöglicht etwas, was einen Konflikt produzieren könnte - also muss die Software (hier: das OS) entweder den Konflikt sauber auflösen, oder dafür sorgen, dass die Situation gar nicht entstehen kann.

Schönen Abend noch,
 Martin

[Johannes Zeller]

Hallo Romy,

gewinnt dann ein Skript und das andere bekommt immer ein cannot access denied oder ist es möglich, dass beide scheinbar gewinnen und keinem Skript ein cannot access mitgeteilt wird? Wenn man diese nacheinander ausführt, bekommt das 2. Skript ein cannot access zurück und der move schlägt logischerweise fehl, da blubber ja nicht mehr da ist.

Verschiebst du auf einer Partition oder zwischen verschiedenen Partitionen? Im letzteren Fall kopiert mv nämlich erst die Datei und löscht dann die Quelldatei. Das lässt sich mit einer hinreichend großen Datei problemlos nachvollziehen. Allerdings, nachdem der Prozess, der als erstes fertig geworden ist, schlägt das Löschen der Datei durch die anderen Prozesse natürlich fehl, da diese schon gelöscht ist; das betrifft aber nicht den Erfolg des Kopiervorgangs.

Schöne Grüße,

Johannes

[Danny]

Hi,

sowas nennt man "race condition". Deshalb immer den Return-Code der Kommandos abfragen oder eine Script- oder Programmiersprache verwenden, die Dateien sperren kann und die Datei sauber sperren/freigeben...

MfG

• Danny