3. Multithreading mit loki

Multithreading mit loki

  • C

    Hi,
    ich habe ziemlich spezielle Fragen:
    und zwar arbeite ich gerade an einem Projekt, bei dem ich die generische Bibliothek "loki" benutzen möchte.
    Nun verwendet mein Programm mehrere Threads und da fängt das Problem leider schon an.
    Z.B. bei der template-Klasse SingletonHolder.
    Hier möchte ich nicht die default-policy SingleThreaded verwenden, sondern wie im Buch von Alexandrescu beschrieben die Klasse ClassLevelLockable benutzen.
    Leider ist scheint die irgendwie nur für Windows-Plattformen programmiert worden zu sein (vorher ist noche ein Makro-Abfrage ala #ifdef _windows_).
    Daher meine erste Frage: Gibt es die auch für Linux-Plattformen?
    Davon mal abgesehen, werden dort static Instanzen deklariert. Allerdings ist doch dann nicht sichergestellt, das diese vor dem ersten Aufruf initialierst worden sind!?
    Das zweite Problem betrifft die SmartPointer. Hier muss ich für mehrere Threads angeblich anstatt DefaultStorage die Klasse LockedStorage benutzen. Ich finde diese in loki überhaupt nicht.
    Kann mir einer dabei helfen bzw hat hier jemand Erfahrung mit loki gemacht?

    Gruß Christian

    0
  • N

    Auf deine Fragen speziell zum Threading kann ich dir keine Antwort gben, damit kenne ich mich nicht aus. Aber in Anhang A von modernes c++ design ist doch ziemlich genau beschrieben was die Threading-Modelle tun müssen. Threading ist systhemabhängig, also musst du eben Linux-Varianten der Funktion benutzen ->
    sieh dir den code fürs threading an, und dann schreib dir was eigenes (so ist das doch eigentlich Gedacht? Stichwort policy-Klassen?)
    :xmas1: :xmas2:

    0
  • C

    Hi Ness,
    naja leider wird zu den Policies wie DefaultStorage nicht genügend Infos gegeben um eine eigene zu entwerfen. Man muss dazu den Code von loki wohl sehr genau studieren.
    Irgendwie sehe bisher bei mir nicht so richtig einen Bedarf loki zu verwenden. Das Buch hat mich zwar sehr dazu motiviert, aber es gibt einige Probleme.
    Z.B. kann ich bei der generischen AbstractFactory keine Parameter bei DoCreate übergeben. Das heißt, die Factory kann nur Objekte erstellen, bei dem im Constructor keine Parameter verlangt werden. Ich finde das ist eine sehr stark Einschränkung. Dadurch wird der ganze Factory-Teil von loki für mich unbrauchbar.
    Außerdem habe ich das Problem, das, wenn man sich stark an das Paradigma der Policies hält, die Code teilweise nicht sehr leserlich durch die vielen template-Parameter wird.
    Alles in allem muss ich sagen das mir das Buch nicht wirklich geholfen hat, im Gegensatz zu der Meinung vieler anderer. Es ist für mich eher Spielerei als das ich es ernsthaft zum Design verwenden kann.
    Ich halte mich wohl eher an die Implementierung von Patterns, wie sie im Buch von Erich Gamma vorgestellt worden.

    Verzweifelte Grüße
    Christian

    PS: Und natürliche auch frohe Weihnachten :xmas1:

    0
  • R

    Im Zweifelsfall schau dir mal boost an. Das enthält viele Teile von Loki (uvm.) und ist Platformunabhängig und wird teilweise in den neuen C++ Standard übernommen.

    0
  • C

    Ich hatte mir boost schonmal etwas angesehen.
    Leider finde ich hier (http://www.boost.org/libs/libraries.htm#Generic) nicht das was ich brauche:
    1. SmartPointer mit Multithread-Synchronisation
    2. generische Implementierung von Design-Patterns.

    Aber trotzdem dank für den Hinweis. Ich werde wohl vieles selbst schreiben müssen 😞

    Gruß Christian

    0
  • ?

    1. ist doch dabei?!?

    0
  • C

    Hi Unbekannter!
    Stimmt du hast recht. Ich muss es übersehen haben.
    Mich würde folgendes interessieren:
    Ich habe bei meinem Code ein bestimmtes Objekt A, welches eine Methode namens
    process() besitzt. In dieser Methode wird ein Thread gestartet, der erstmal einige Zeit läuft.
    Nun besitzen andere Objekte Zeiger auf A.
    Diese wollen nun über diese Zeiger auf A Operationen durchführen.
    Die Frage ist für mich: reicht es einfach aus für die Zeiger shared_ptr zu nehmen?
    Immerhin läuft ja ständig ein Thread, der irgendwann mal dort gestartet wurde...

    Gruß Christian

    0
  • C

    Obwohl, ganz so sicher scheinen die shared_ptr's auch nicht zu sein.
    Hier von der Dokumentation:

    shared_ptr<int> p(new int(42));

//--- Example 1 ---

// thread A
shared_ptr<int> p2(p); // reads p

// thread B
shared_ptr<int> p3(p); // OK, multiple reads are safe// thread A
...
//--- Example 3 ---
p = p3; // reads p3, writes p

// thread B
p3.reset(); // writes p3; undefined, simultaneous read/write

    Also bieten die boost-SmartPointer doch keinen Schutz gegen mehrfachen schreib- und lese-Zugriff??!

    0
  • C

    *push*

    0
Anmelden zum Antworten