Anzeige:
Ergebnis 1 bis 6 von 6

Thema: [python]: asyncore, select, threads, etc.?

  1. #1
    Registrierter Benutzer
    Registriert seit
    11.08.2003
    Beiträge
    14

    [python]: asyncore, select, threads, etc.?

    hallo zusammen ...

    ich wollte gerade anfangen einen kleinen datenbankdaemon zu schreiben, und habe dann gemerkt: ups - das ding muss ja auch mehrere verbindungen auf einmal koennen. jetzt habe ich mal losgelegt und versucht zu durchdenken wie man das machen kann:

    eine moeglichkeit waere ja das ding per sockets an den rest der anwendung anzubinden - is zwar etwas overkillt, aber solange es funktioniert stoerts ja keinen. mein problem an sockets ist, dass ich a) mit select und b) mit threading nicht ganz klarkomme. soweit ich das verstanden habe erstell ich mir ja ein socket, lasss es auf irgendeinem port hoeren, und warte dann bis select mir sagt, dass es les oder schreibbar ist. dann starte ich einen neuen thread und arbeite die verbindung dort ab, waerend der 'mutterthread' weiter horcht.

    ansonsten koennte man ja irgendwie versuchen was mit threads ohne sockets hinzubringen - es gibt doch bestimmt moeglichkeiten mehrere threads untereinander kommunizieren zu lassen, oder?

    dann habe ich noch in der py docu asyncore gesehen. scheint ja auf den ersten blick genau das zu sein was ich brauche - waere es nur so dokumentiert, dass ich es verstehe -.-. ich glaube ein asyncore (oder medusa) beispiel wie man mehrere verbindungen abhandelt, und "gleichzeitig" (ja ich weiss, dass es kein gleichzeitig gibt. nein ich habe nur eine cpu *g aber wenigstens pseudo gleichzeitig) noch nach neuen verbindungen horcht.

    waere super wenn mir jemand von euch helfen koennte

  2. #2
    Registrierter Benutzer
    Registriert seit
    05.09.2002
    Ort
    Neuhausen
    Beiträge
    320
    Zitat Zitat von Nebukadneza
    eine moeglichkeit waere ja das ding per sockets an den rest der anwendung anzubinden - is zwar etwas overkillt, aber solange es funktioniert stoerts ja keinen.
    Der Lerneffekt ist auf jedenfall da.
    ansonsten koennte man ja irgendwie versuchen was mit threads ohne sockets hinzubringen - es gibt doch bestimmt moeglichkeiten mehrere threads untereinander kommunizieren zu lassen, oder?
    Klar. Select ist nicht notwendig. Der Mutterthread wartet auf eine Verbindung (blockierend). Wenn eine Verbindung passiert spaltet er einen neuen Thread ab, welche sich um die Verbindung kümmert und wartet wieder blockierend auf die nächste Verbindung.

    Select ist für Situationen gedacht, in denen auf mehrere Sockets (Allgemein: lesend auf Filedescriptors) gewartet werden muss. Es blockiert solange bis von einem Filedescriptor gelesen werden kann. Zusätzlich erlaubt select es auch einen Timeout anzugeben, um damit z.B. Pollend auf einen Filedescriptor zuzugreifen (Damit kann in einem Thread/Prozess die Benutzeroberfläche aktualisiert werden und trotzdem auf Daten an einem oder mehreren Filedescriptoren gewartet werden. Der Timeout wird übrigens auch oft als Portable Pause eingesetzt.)

    Python hat einfach zu verwendende Threads (import thread) und erweiterte (import threading). Sobald threads zum Einsatz kommen, muss durch locking-Mechanismen gewährleistet werden, dass nie gleichzeitig Threads auf gemeinsam verwendete Daten zugreiffen. Auch dafür gibt es Lock-Objekte in der Bibliothek.

    Gruss, Andy

  3. #3
    Registrierter Benutzer Avatar von fs111
    Registriert seit
    23.03.2002
    Beiträge
    594
    Sehr praktisch für die Datenhaltung für mehrere Threads sind die Queues, die sind threadsicher, und einfach anzuwenden. Ich nutze die im Moment für größere Datenmengen, und das klappt ohne Probleme:

    http://python.org/doc/current/lib/module-Queue.html

    fs111

  4. #4
    Registrierter Benutzer
    Registriert seit
    11.08.2003
    Beiträge
    14
    ok - erstmal danke fuer die antworten

    zu dem queue zeug: is gut zu wissen, dass es sowas gibt aber ich glaube das is nich so ganz was ich suche. was mich eben interessieren wuerde ist: wenn ich 2 threads habe - der eine hate daten auf die der andere zugreiffen will - wie genau geht das? und wie genau funktioniert dieser ganze locking krempel? ich hab die doku dazu zwar schon durchgerackert, allerdings erklaert das ding ja mehr syntax/aufbau und weniger wie es funktioniert/man es benutzt.

    aber danke schonmal

  5. #5
    Registrierter Benutzer
    Registriert seit
    05.09.2002
    Ort
    Neuhausen
    Beiträge
    320
    Na ein bisschen Theorie schadet nie...

    Es gibt im Netz bestimmt eine Seite die das näher erläutert. Ich versuche mal das wichtigste zu erwähnen:

    Um gleichzeitigen Zugriff zweier Prozesse (gilt natürlich auch für Threads) braucht man atomare Operationen, d.h. Prozessorinstruktionen die nicht vom Scheduler unterbrochen werden können (z.B. mov, xchg, etc.). Auf einem Einprozessorsystem kann zwar nicht gleichzeitig auf den Speicher zugegriffen werden, aber der Scheduler kann jederzeit einen Prozess schlafen legen und den nächsten ausführen.
    Obwohl es Möglichkeiten gibt in reiner Software Mutual Exclusion (schon wieder ein Begriff dafür...) zu implementieren haben die Prozessoren spezielle, von Hardware unterstütze Befehle für diese Aufgabe. Im Programm selber greift man auf diese über Betriebsystem-Funktionen zu, wie z.B. Semaphoren oder Mutex.

    Nun, wie setzt man das ein? Nehmen wir an wir haben zwei Prozesse die eine gemeinsame Variable A verwenden. Dafür haben beide Prozesse vom System einen gemeinsamen Lock (Mutex) M angefordert.

    Prozess1:
    aquire_lock(M)
    work_with_data(A)
    release_lock(M)

    Prozess2:
    aquire_lock(M)
    do_something_with_data(A)
    release_lock(M)

    Das klappt soweit gut. Wenn ein Prozess im geschützten Abschnitt (zwischen aquire und release) ist, und der andere ebenfalls den geschützten Abschnitt betreten will, blockiert der Systemaufruf "aquire_lock" den Prozess so lange bis M wieder freigegeben wurde.

    Probleme kommen erst, wenn in dem geschützten Abschnitt weitere Locks angefordert werden. In diesem Fall kann es passieren dass beide Prozesse auf die Freigabe eines der Locks warten und sich so gegenseitig in den Schwanz beissen wollen. Die Folge: Das Programm blockiert so lange bis ewig... Wir haben einen Deadlock.

    Natürlich kann das noch optimiert werden: Wenn man zwischen schreibendem und lesendem lock unterscheidet, so können mehrere lesende Prozesse im kritischen Abschnitt erlaubt werden, nur wenn ein Prozess schreibend zugreift braucht er den Zugriff exklusiv.

    Um noch einem Gedankenfehler vorzubeugen: Auch wenn die Daten nur gelesen werden, muss die Operation geschützt werden. Sonst könnte es passieren, dass z.B. beim Lesen eines Strings der String durch den zweiten Prozess in der hälfte geändert wurde oder gar freigegeben. Solche Daten-Zerstückelungen sind sehr schwierig zu lokalisieren und treten nur sporadisch auf.

    So, für alles weitere verweise ich an die Fachliteratur.

    Die Queues, wie sie fs111 erwähnt habt ist eine feine Sache: Sie übernehmen das Locking, d.h. du schiebst Daten rein und liest sie wieder auf. Sollte die Queue gerade leer sein (beim lesen), so blockiert dein Programm bis wieder Daten anstehen. Damit kannst du z.B. Pipes realisieren.

    Bei Python solltest du bedenken, dass die Daten zwischen den Threads kopiert werden. Wenn nur eine Zuweisung erfolgt, kopiert du zwar sicher die Referenz, aber die verweist immernoch auf den gleichen Speicher. Hier könnte das Copy-Modul helfen.

    Gruss, Andy

  6. #6
    Registrierter Benutzer
    Registriert seit
    11.08.2003
    Beiträge
    14
    hm ... ok - das hilft schonmal deutlich weiter. genau so eine zusammengfasste 'anleitung' hab ich im netz nicht gefunden.

    also tausend dank mal!

    wo ich mich allerdings noch ein bisschen stosse is das kopiere usw zwischen threads.

    also jetzt nehmen wir mal an ich habe in meinem hauptprogramm eine variable
    a=10
    diese gebe ich an 2 threads. wenn ich die variable in einem thread aendere aendert sie sich auch im anderen, da das was ich da uebergeben hab nur der verweise auf die stelle im ram ist (so pointer artig), oder?

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •