multithread + crossplatform-entwicklung

akari

Hallo

und auch boost::thread ist portabel.

bis bald
akari

noq

hmmm, sehen beide interessant aus und ich denke ich werd dort mal genauer reinschaun.

Aber Tutorials gibt es in dem bereich nicht? kann mir jemand ein posix tutorial auf deutsch (englisch geht natürlich auch) empfehlen, wo vielleicht die unterschiede zu windows zu erkennen sind?

mawis

Auch Glibmm bietet platform-unabhängige Threads unter Windows und vielen Unices an.

joomoo

das hier gefällt mir sehr gut: http://www.kharchi.de/threads.html

mfg.

hustbaer

Threads sind ein heikles Thema. Boost.Thread ist IMHO keine gute Wahl. Wobei... ich keinen wirklich viel besseren Vorschlag habe. Qt oder ZThreads vielleicht - optimal sind beide auch nicht.

akari

Hallo

hustbear : Begründung?

bisb ald
akari

Artchi

Also Boost.Thread wird bereits in einigen Projekten intensiv eingesetzt. Auch von namhaften Firmen (z.B. von Real Networks und Adobe) und von diversen Opensource Projekten (z.B. http://hydranode.com/).

Wieso sollte es keine gute Wahl sein?

hustbaer

ist der Author verschollen, und daher das Copyright ein Problem, sobald irgendjmd. etwas an Boost.Thread ändern will (was auch der Grund ist warum sich da nie was ändert).
ist die ganze xtime Geschichte ein einziger riesen Murks, und nicht sicher (wenn die Systemzeit im richtigen Moment verstellt wird kann man statt 1 Sekunde schnell mal 1 Stunde warten, oder 1 Jahr, oder für immer). Und ganz davon abgesehen halte ich es für einen ziemlichen Murks relative Timeouts so umständlich zu machen - aber damit könnte ich noch leben, da gibts ja auch Workarounds.
ist die Implementierung der Condition-Variablen undurchschaubar und langsamer als nötig. Ich sage nicht sie wäre nicht korrekt, bloss um das zu verstehen was da abgeht muss man sich schonmal recht lange hinsetzen, und um zu beweisen dass es wasserdicht ist noch viel länger.
ist das "manuell lock Verbot" etwas kindisch (und störend) - manchmal braucht man eben direkten Zugriff auf "lock" und "unlock" - und in Boost.Thread gibt es *keinen* Weg der kein riesen übler Hack (=undefined behaviour was halt "trotzdem geht" weil man den Compiler gut genug kennt) wäre um das zu tun.

BTW: die APR (Apache Portable Runtime) wird auch von einigen grossen Projekten verwendet, der Windows Code ist aber so grässlich und unvollständig dass ich mir lieber gleich mit einer Glock in den Fuss schiessen würde, da kann ich wenigstens noch zielen
(Wenn man weiss welche Teile man verwenden kann und welche nicht ist die APR wahrscheinlich OK, aber das ist für jmd. der sich das Teil man schnell zieht und verwendet nicht offensichtlich)

hustbaer schrieb:

ist das "manuell lock Verbot" etwas kindisch (und störend) - manchmal braucht man eben direkten Zugriff auf "lock" und "unlock" - und in Boost.Thread gibt es *keinen* Weg der kein riesen übler Hack (=undefined behaviour was halt "trotzdem geht" weil man den Compiler gut genug kennt) wäre um das zu tun.

Das versteh ich nicht, musst du mir mal erklären.

hustbaer

@asdafcvbc:

void foo()
{
    boost::mutex m;
    m.lock(); // geht net
    m.unlock(); // geht auch net

    boost::mutex::scoped_lock l(m); // einzige möglichkeit net mutex zu locken
}

Bei dem einfachen Beispiel: egal, klar. Aber nichtmehr egal wenn man mal einen Fall hat wo man einfach lock() und unlock() wie oben skizziert direkt aufrufen muss. Denn das geht in Boost.Thread eben nicht.

Artchi

Ehm, und wo ist jetzt konkret das Problem? Du willst es nur anders machen, aber die Auswirkung/Verhalten ist doch die gleiche.

tntnet

Also ich habe schon mindesten ein mal die Situation, wo ich einen Lock explizit frei geben wollte, ohne den scope zu verlassen. Hier ein Beispiel:

void foo()
{
  static boost::muxtex m; // ein lokaler Mutex macht wenig Sinn - oder?
                          // daher habe ich ihn static gemacht
  boost::mutex::scoped_lock l(m);
  if (irgendeine Bedingung)
  {
    // jetzt würde ich gerne den Lock frei geben
    l.unlock();

    // hier nur noch thread-safe Operationen, aber dafür parallel
  }
}

es geht natürlich auch ohne, aber umständlicher:

void foo()
{
  static boost::muxtex m; // ein lokaler Mutex macht wenig Sinn - oder?
                          // daher habe ich ihn static gemacht

  {
    boost::mutex::scoped_lock l(m);
    if (!irgendeine Bedingung)
      return;
  }

  // hier nur noch thread-safe Operationen, aber dafür parallel
}

Tntnet

Artchi

Achso, also es soll je nach Bedinung in einem Scope das Lock gesteuert werden können. Hem, was ist wenn ich das Lock (ich habs nicht ausprobiert, nur eine Idee) dynamisch anlege?

void foo()
{
  static boost::muxtex m; // ein lokaler Mutex macht wenig Sinn - oder?
                          // daher habe ich ihn static gemacht

  std::auto_ptr<boost::mutex::scoped_lock> l(new boost::mutex::scoped_lock(m));
  if (irgendeine Bedingung)
  {
    // jetzt würde ich gerne den Lock frei geben
    l.release();

    // hier nur noch thread-safe Operationen, aber dafür parallel
  }
}

Artchi

Übrigens, ein normales Lock (http://www.boost.org/doc/html/threads/concepts.html#threads.concepts.Lock) gibts ja auch noch. Mit der Kombination des Autopointers wäre das doch eine Option?

hustbaer

@tntnet: das in deinem Beispiel liesse sich noch durch ein "scoped unlock" lösen. Weiss jetzt aber nicht auswändig ob Boost.Thread das anbietet oder nicht...

@Artchi: es gibt manchmal Fälle wo weder das normale "lock" Objekt noch das "scoped lock" ausreichen. Guck dir z.B. die Beispielimplementierung von Kevlin Henneys Proposal an: http://boost-consulting.com/vault/index.php?action=downloadfile&filename=thread_new.1.1.zip&directory=Concurrent Programming&
Da wird ein brutaler Hack verwendet, bloss weil lock und unlock nicht direkt aufrufbar sind. Den genauen Grund hab ich vergessen, steht aber in Code-Kommentaren erklärt.

Das "lock" Objekt dynamisch anlegen könnte vielleicht sogar in allen Fällen reichen (müsste ich länger drüber nachdenken ob's Fälle geben kann wo das nicht reicht - und mag mein Hirn grad nicht verbiegen *g*), aber das halte ich für zuviel Overhead und für zu "unschön" (obwohl manuell locken natürlich sowieso schon unschön ist...).

----

Es bleiben aber wenn wir Punkt 4 mal in Frage stellen dennoch die Punkte 1-3 die zusammengenommen (zumindest für mich) ein grossen Minus ergeben.

EDIT: Link korrigiert