STL-Container blockieren Thread

christian123

Hm ja der Code ist leider länger, aber du musst es dir im Prinzip so vorstellen (es ist jetzt wirklich nur ganz primitiv und vereinfacht):

...
void dummy(void) {
  list<int> l;
}

class ThreadClass {
private:
  bool closeThread;
  Mutex mutex;
public:
  ThreadClass() : closeThread(false) {}
  void threadProcess(void) {
    bool closeThreadTemp;
    do {
      dummy();
      mutex.getAccess();
      closeThreadTemp = closeThread;
      mutex.freeAccess();
    }
    while(!closeThreadTemp);
  }
  close(void) {
    mutex.getAccess();
    closeThread = true;
    mutex.freeAccess();
  }
};

Also folgendes:
Es werden einfach irgendwo anders Threads erzeugt (so ca. und jeder Thread bekommt ein eigenes Objekt von der Klasse ThreadClass.
Jeder Thread führt dann threadProcess() aus.
Will ich nun alle Threads schließen, rufe ich bei allen Instanzen von ThreadClass einfach close auf.
Leider passiert da meistens gar nichts.
Wenn ich aber list< int > wegnehmen funktioniert es. Und selbst wenn ich irgendein anderes (nicht STL) Objekt erzeuge funktioniert es.
Also muss es irgendwas mit dem std::allocator zu tun haben oder?

Gruß Christian

Walli

Welche STL-Implementierung hast du denn? Wenn ich mich nicht irre muss man bei manchen Implementierungen irgendein define o.ä. setzen, wenn man die Lib in einem multithread-Programm einsetzen will.

Vielleicht liegt es aber nicht an der Erzeugung der List, sondern daran, was du danach mit ihr machst...

christian123

Ich verwendet den gcc 3.3.1. Ich weiß nicht genau welche Implementierung der STL dahinter steht.
Auf jedenfall gibt es auch dann Probleme wenn ich mit list< int > nichts weiter mache. Deswegen der Verdacht mit dem allocator.

Walli

Wenn mich nicht alles täuscht, dann sollte die beiliegende STL von Haus aus Threadsicher sein.
Hast du mal probeweise den dummy-Aufruf in den kritischen Bereich gepackt? Wenns am Multithreading liegt, dann würde hier ja eigentlich kein Fehler auftreten.

Kann es vieleicht daran liegen, dass ein Thread z.B durch eine exception beendet wird, aber noch im besitz der Mutex ist?

EdiRitter

Hallo,

Anscheinend wird mein Programm blockiert, wenn mehrere Threads "parallel"

Ich weiß nicht so recht was ich machen soll?

Such bei google nach Prozesssynchronisation, Reader Writer-, Erzeuger/Verbraucher Problem

Oder hier:
http://www.informatik.uni-leipzig.de/rnvs/lindemann/V05-Synchronisation.pdf

MfG

christian123

@master:
Ja genau, sobald der Aufruf im kritischen bereich ist, geht alles bestens.
Interessanterweise habe ich folgendes herausgefunden:

set< int, less< int >, __allocator<int, __default_alloc_template<false,0 > > >

macht keine Probleme mehr.

set< int, less< int >, __allocator<int, __default_alloc_template<true,0 > > >

hingegen schon.
Hier aus der STL:

template<bool __threads, int __inst>
  class __default_alloc_template

Zum ersten Template-Parameter steht, dass dieser angibt ob mehr als einen Thread benutzt werden.
Müsste es nicht umgekehrt sein, weil es geht ja nur wenn der erste templ.Parameter false ist.
Hm gibt es irgendwie eine allgemeine Einstellung, das ich nur diesen Allocator benutze?

@samo:
In meinem richtigen Programm hatte ich für diesen Fall schon gesorgt. Aber sonst wäre es sicher eine Möglichkeit, das stimmt.

@EdiRitter:
Danke, aber ich komme mit Multithreading und Synchronisation schon ganz gut klar. Das Problem liegt diesmal wahrscheinlich wirklich nicht bei mir, sondern bei einer STL Einstellung (siehe die restlichen Beiträge hier).

Walli

Musst mal in der Doku zu deiner STL schauen, ob es da irgendeinen compiletime-switch gibt, mit dem man die lib auf multithreaded umschalten kann. Ne andere sinnvolle Maßnahme fällt mir spontan auch nicht ein.

christian123

Hm wo müsste ich da nachgucken?
Bei der Suche im Internet lande ich immer bei SGI.
Bin ich dort richtig?

christian123

Außerdem ist es doch sehr mysteriös.
Es funktioniert:
set< int, __single_client_alloc >
und nicht:
set< int, __alloc >

?????