Storable->retrieve parallel aus einem weiteren Programm? (Allgemeines zu Perl)

[thread]14081[/thread]

Storable->retrieve parallel aus einem weiteren Programm?

Leser: 25

Articles: hide open all | hide show old branches

+13 replies
toby

2009-09-30 15:28

User since
2006-04-14
66 Artikel
BenutzerIn

Hi Leute,

ich nutze "use Storable qw(nstore retrieve);" um den aktuellen hash-Zustand auf die Platte zu schreiben, bzw beim Start meines Daemons den letzen Zustand zurück zu holen.

Wie verhält sich der gespeicherte Hash, wenn man ihn parallel von einem weiteren Perlprogramm mit retrieve holt? Darf man das, oder kommen sich die beiden Programme in die Quere, was den gespeicherten Hash zerstören kann? Wie kann ich dann sonst safe auf diesen gespeicherten Hash von einem anderem Programm (zum auswerten, also nur als read-only) zugreifen?

Danke! :)
Toby
- +12 replies
- pq
  
  2009-09-30 15:38
  User since
  2003-08-04
  12209 Artikel
  Admin1
  aus der doku (ich habe einfach nur nach "lock" gesucht):
  
  Code: (dl )
  
  1 2 3 4 5 6 7 8 9 10
  
  # Advisory locking use Storable qw(lock_store lock_nstore lock_retrieve) lock_store \%table, 'file'; lock_nstore \%table, 'file'; $hashref = lock_retrieve('file'); [...] The "lock_store" and "lock_nstore" routine are equivalent to "store" and "nstore", except that they get an exclusive lock on the file before writing. Likewise, "lock_retrieve" does the same as "retrieve", but also gets a shared lock on the file before reading.
  
  Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
  lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
  - +11 replies
  - toby
    
    2009-09-30 16:21
    User since
    2006-04-14
    66 Artikel
    BenutzerIn
    
    Hi,
    
    Code: (dl )
    
    1 2 3
    
    [...] get an exclusive lock on the file before writing. [...]
    
    will heissen, dass es nur kurzfristig für den Schreibzugriff ge'lock'ed wird und nachher wieder freigegeben? Das hieße dann auch also, ich darf vom anderen Programm aus parallel auf den gleichen Store zugreifen und es dürfte keine Probleme geben?
    
    Danke noch mal! :)
    Toby
    - +10 replies
    - pq
      
      2009-09-30 16:27
      
      User since
      2003-08-04
      12209 Artikel
      Admin1
      
      ja, es arbeitet halt im hintergrund mit flock. noch gar nicht mit file-locking in perl gearbeitet?
      perldoc -q lock
      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
      lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
      - +9 replies
      - toby
        
        2009-09-30 16:56
        
        User since
        2006-04-14
        66 Artikel
        BenutzerIn
        
        Hi pq :)
        
        > noch gar nicht mit file-locking in perl gearbeitet?
        
        Doch, doch. Hier hat mich es aber etwas unsicher gemacht, da es sich um den gespeicherten Hash handelt und ich wollte die Datenstruktur durch gleichzeitigen Zugriff aus einem anderen Programm, nicht zerstören. Ich dachte halt, dass durch retrieve(), vielleicht ein Filedeskriptor offen bleibt und der parallele Zugriff etwas durcheinander bringt. Es scheint aber unbegründete Sorge gewesen zu sein :)
        
        Vielen Dank! :)
        Toby
        
        +2 replies
        
        pq
        
        2009-09-30 17:35
        
        User since
        2003-08-04
        12209 Artikel
        Admin1
        
        du musst halt auch lock_retrieve verwenden, sonst kann es passieren, dass du eine unvollständig geschriebene datei erwischst.
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        toby
        
        2009-10-01 09:18
        
        User since
        2006-04-14
        66 Artikel
        BenutzerIn
        
        danke schön! :)
        
        Toby
        
        +6 replies
        
        sid burn
        
        2009-10-01 09:59
        
        User since
        2006-03-29
        1520 Artikel
        BenutzerIn
        
        Wenn du die Datei nur einmal geschrieben hast, und nicht mehr neu schreibst kannst du auch ohne probleme die Datei mehrmals parallel einlesen ohne locking.
        
        Locking beim Lesen brauchst du nur dann wenn du die Datei nachträglich änderst und neu schreibst. Weil du dann genau dann einen Moment beim auslesen erwischen kannst wenn du die Datei neu schreibst.
        
        Wenn du allerdiengs auf einen Linux System (generell Unix Systeme) arbeitest kannst du rein theoretisch durch temp datei schreiben / rename es auch so hinbiegen das du ohne locking immer wieder lesen kannst ohne in probleme zu rennen. Das wäre dann aber nicht mehr Platformunabhängig.
        Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
        
        +5 replies
        
        toby
        
        2009-10-01 11:05
        
        User since
        2006-04-14
        66 Artikel
        BenutzerIn
        
        Hi,
        
        Quote
        Wenn du allerdiengs auf einen Linux System (generell Unix Systeme) arbeitest
        kannst du rein theoretisch durch temp datei schreiben / rename es auch so hinbiegen
        das du ohne locking immer wieder lesen kannst ohne in probleme zu rennen.
        
        Ich arbeite nur unter Unix (HP-UX). Mein erster Gedanke war aus B.pl mir die Datei wegzukopieren und dann die Kopie auszulesen und anschliessend wegzuschmeissen. Dies ist zwar sicher, erschien mir aber zu umständlich und wollte wissen, ob es direkt mit Perl-Board-Mitteln geht.
        
        Quote
        Locking beim Lesen brauchst du nur dann wenn du die Datei nachträglich änderst und neu schreibst.
        Weil du dann genau dann einen Moment beim auslesen erwischen kannst wenn du die Datei neu schreibst.
        
        Das eine Programm A.pl (daemon) schreibt kontinuierlich, aber ungegelmäßig rein. Das andere, parallele Programm B.pl liest die Datei nur ab und zu aus, um den aktuellen Zustand für andere Zwecke auszuwerten.
        
        Meine angedachte Vorgehensweise nach Tipps von pq war lock_nstore() beim A.pl und lock_retrieve() bei B.pl. Da ich mich aber mit dem Lock- und Store-Verhalten bei unabhängigen, parallelen Zugriffen nicht auskenne habe ich nun doch noch folgende Sorgen:
        
        Was macht A.pl, wenn es schreiben möchte und die Datei gerade vom B.pl für Lesen ge'lock'ed ist? Der deamon (A.pl) darf nie Probleme haben über die Datei zu verfügen, wogegen bei B.pl nicht so ganz wichtig ist, wenn er Probleme beim Lesen bekommt. Natürlich wäre es am schönsten, wenn weder A.pl noch B.pl Probleme bekommen. Da ich aber nicht weiss, wie sich gleichzeitiges lock_retrieve() vom B.pl und lock_nstore() vom A.pl verhält, ist mein aktueller Plan lock_nstore() bei A.pl und normales retrieve() bei B.pl mit der Gefahr, dass B.pl evtl. zerschnittene Daten erhält. Was meint ihr darüber?
        
        => Wenn A.pl mit lock_nstore() wartet, bis lock_retrieve() von B.pl fertig ist, wäre alles OK, wie läuft es aber tatsächlich ab? Wie gesagt, das Wichtigste ist, dass A.pl problemlos reinschreiben darf!
        
        Danke und viele Grüße! :)
        Toby
        
        PS: lock_store(), oder lock_nstore() ? Wo ist der Unterschied???
        
        Last edited: 2009-10-01 11:12:12 +0200 (CEST)
        
        +3 replies
        
        pq
        
        2009-10-01 11:38
        
        User since
        2003-08-04
        12209 Artikel
        Admin1
        
        2009-10-01T09:05:29 toby
        Meine angedachte Vorgehensweise nach Tipps von pq war lock_nstore() beim A.pl und lock_retrieve() bei B.pl. Da ich mich aber mit dem Lock- und Store-Verhalten bei unabhängigen, parallelen Zugriffen nicht auskenne habe ich nun doch noch folgende Sorgen:
        
        hast du perldoc -q lock gelesen?
        
        Quote
        Was macht A.pl, wenn es schreiben möchte und die Datei gerade vom B.pl für Lesen ge'lock'ed ist? Der deamon (A.pl) darf nie Probleme haben über die Datei zu verfügen,
        
        was meinst du mit problemen? der prozess wartet halt, bis er dran ist. das handelt sich ja im schlimmsten fall nur um millisekunden.
        
        Quote
        Natürlich wäre es am schönsten, wenn weder A.pl noch B.pl Probleme bekommen. Da ich aber nicht weiss, wie sich gleichzeitiges lock_retrieve() vom B.pl und lock_nstore() vom A.pl verhält, ist mein aktueller Plan lock_nstore() bei A.pl und normales retrieve() bei B.pl mit der Gefahr, dass B.pl evtl. zerschnittene Daten erhält. Was meint ihr darüber?
        
        warum?
        glaubst du, ich gebe dir einen tip, damit du probleme bekommst? wenn du ein *normales* retrieve nimmst, *dann* kriegst du probleme, weil es sein kann, dass die datei gerade geschrieben wird.
        ich kapier nicht, wieso du jetzt alles vorherige fallen lässt und dir irgendwas ausdenkst, was deiner meinung nach sicherer sein könnte.
        file locking ist das, was du willst, und wenn du nur die hälfte davon benutzen willst, wird es halt schief gehen. ich kann dich natürlich nicht zwingen, mir zu glauben.
        
        Quote
        => Wenn A.pl mit lock_nstore() wartet, bis lock_retrieve() von B.pl fertig ist, wäre alles OK, wie läuft es aber tatsächlich ab? Wie gesagt, das Wichtigste ist, dass A.pl problemlos reinschreiben darf!
        
        lies die doku!
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        +2 replies
        
        toby
        
        2009-10-01 11:55
        
        User since
        2006-04-14
        66 Artikel
        BenutzerIn
        
        Hallo! :)
        
        > hast du perldoc -q lock gelesen?
        Nur perldoc Storable. Hier hat mich aber das Verhalten beim parallele Zugriff von zwei komplett unabhängigen Programmen verunsichert.
        
        > der prozess wartet halt, bis er dran ist. das handelt sich ja im schlimmsten fall nur um millisekunden.
        Genau das habe ich in der Doku (zu Storable) im Bezug auf zwei komplett unabhängige Programme (Prozesse) nicht gefunden.
        
        >ich kann dich natürlich nicht zwingen, mir zu glauben.
        >[...]
        > glaubst du, ich gebe dir einen tip, damit du probleme bekommst?
        
        Natürlich nicht. Sorry, wenn es so rüber gekommen ist!
        
        Nichts für ungut. Lieben Dank für die Hilfe! Habe gerade lock_nstore und lock_retrieve implementiert :)
        
        Danke noch mal und sorry, wenn es falsch rüber kam! :)
        Toby
        
        pq
        
        2009-10-01 12:39
        
        User since
        2003-08-04
        12209 Artikel
        Admin1
        
        2009-10-01T09:55:31 toby
        > hast du perldoc -q lock gelesen?
        Nur perldoc Storable. Hier hat mich aber das Verhalten beim parallele Zugriff von zwei komplett unabhängigen Programmen verunsichert.
        
        ich hatte ja perlfoc -q lock schon erwähnt. dort gibt es dann noch einen hinweis auf perldoc perlopentut.
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        sid burn
        
        2009-10-02 10:20
        
        User since
        2006-03-29
        1520 Artikel
        BenutzerIn
        
        Quote
        Ich arbeite nur unter Unix (HP-UX). Mein erster Gedanke war aus B.pl mir die Datei wegzukopieren und dann die Kopie auszulesen und anschliessend wegzuschmeissen. Dies ist zwar sicher, erschien mir aber zu umständlich und wollte wissen, ob es direkt mit Perl-Board-Mitteln geht.
        
        Mit Kopieren hat das nichts zu tun. Was ich meinte ist folgende vorgehensweise. "dateia" nutzen derzeit alle zum auslesen. Dein Programm schreibt neue Daten ersteinmal in "dateib". Nachdem es fertig ist benennst du "dateib" nach "dateia" um. Um es kurz zu halten. Soetwas stellt unter Unix ähnlichen Betriebssystem kein Problem dar, unter Windows würde dies nicht gehen.
        
        Der andere Punkt war einfach nur ein Hinweis das wenn du "immutable" dateien hast (Dateien die sich nicht verändern). Dann brauchst du auch kein locking. Das ist als Antwort darauf weil du fragtest ob es Probleme gibt wenn zwei Programme gleichzeitig eine Datei lesen. Lesen generell stellt kein Problem dar. Probleme gibt es immer nur dann wenn du Änderungen erlaubst bzw. gleichzeitig Liest/Schreibst. Dann musst du mit Locking arbeiten.
        
        Quote
        Das eine Programm A.pl (daemon) schreibt kontinuierlich, aber ungegelmäßig rein. Das andere, parallele Programm B.pl liest die Datei nur ab und zu aus, um den aktuellen Zustand für andere Zwecke auszuwerten.
        
        Somit kann es einen Moment geben wo gleichzeitig gelesen/geschrieben wird. Daher um es einfach zu halten solltest du Locking nutzen. Erstes was ich aber schrieb geht auch.
        
        Vorteil wäre das du kein Locking hast, und du damit wirklich Parallel arbeitest. Mit Locking greift immer nur einer gleichzeitig auf die Datei zu.
        
        Allerdiengs spielt das wenn du nur selten auf die datei zugreifst sowieso alles keine Rolle und von der vorgehensweise ist es simpler einfach das locking prinzip zu nutzen.
        
        Wo es eine Rolle spielen würde wäre wenn du hunderte abfragen pro sekunde hättest. Dann wäre es aber sinvoller wohl gleich ein TCP/IP Server aufzubauen anstatt es über das I/O zu machen.
        
        Quote
        Meine angedachte Vorgehensweise nach Tipps von pq war lock_nstore() beim A.pl und lock_retrieve() bei B.pl. Da ich mich aber mit dem Lock- und Store-Verhalten bei unabhängigen, parallelen Zugriffen nicht auskenne habe ich nun doch noch folgende Sorgen:
        
        Naja Locking ist ja gerade dafür da wegen "Paralleln" Zugriff, wenn du kein Parallelen zugriff hättest brauchst du auch kein Locking.
        
        Quote
        Was macht A.pl, wenn es schreiben möchte und die Datei gerade vom B.pl für Lesen ge'lock'ed ist?
        
        Er wartet solange bis er den Lock bekommt und schreibt dann, sprich dein Programm stoppt, sofern du kein "non-blocking lock" machst.
        
        Quote
        PS: lock_store(), oder lock_nstore() ? Wo ist der Unterschied???
        
        Storable speichert Daten Binär ab. Unterschiedliche Architekturen haben sogenannte BigEndian oder LittleEndian, das gibt an wie Bits zu Interpretieren sind. Nutzt du nur "lock_store" dann wird das Verfahren deiner Maschiene genutzt.
        
        Wenn du Daten aber mit Storable z.B. über Rechner hinweg austauscht, Sprich über Netzwerk etc. dann ist es ziemlich nachteilig wenn ein Rechner in LittleEndian Speichert und der andere es als BigEndian versucht zu interpretieren, das läuft dann schief.
        
        Das "n" gibt an das du die Netzwerkordnung nutzen möchtest. Daher Daten sind auch über Systeme austauschbar die das eine oder das andere verfahren nutzen.
        
        Für genaueres kannst du das hier lesen: http://de.wikipedia.org/wiki/Byte-Reihenfolge
        Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de

View all threads created 2009-09-30 15:28.