C/C++: Speicherallokierung und pthreads

[amiga]

hi :)

habe mal eine Frage bezüglich malloc()/free() bzw. new/delete in Verbindung mit pthreads :

In Programmen, die pthreads verwenden, kommt es bei mir manchmal zufälligen Abstürzen (Segmentation Faults), wenn man malloc() aufruft.

malloc() scheint da nicht thread-sicher zu sein.

Habe es jetzt mit pthread_mutex_lock() und pthread_mutex_unlock() gekapselt, das sieht etwa so aus (codeschnipsel) :



#include <pthread.h>
...

pthread_mutex_t g_mtxMemory;

void *thread_malloc(size_t s)
{
void *x;
pthread_mutex_lock(&g_mtxMemory);
x = malloc(s);
pthread_mutex_unlock(&g_mtxMemory);
}

void thread_free(void *x)
{
pthread_mutex_lock(&g_mtxMemory);
free(x);
pthread_mutex_unlock(&g_mtxMemory);
}

int main()
{
pthread_mutex_init(&g_mtxMemory,NULL);

// ... code ...

pthread_mutex_destroy(&g_mtxMemory);
return 0;
}


Meine Frage ist nun : ist das eine sinnvolle Lösung ? Gibts da evtl noch eine andere Möglichkeit um malloc thread-safe zu bekommen ?

Was mich auch mal interessieren würde : Wie verhalten sich "new" und "delete" in C++ ? Kann man die Funktionen als threadsafe ansehen ?


Gruß, amiga

[RapidMax]

Thread-safety: thread-safe unless NO_THREADS is defined
Du hast mich gerade ein bisschen unsicher gemacht. In der Standard-Bibliothek steht aber genau das oben aufgeführte Zitat, was auch meinen bisherigen Kentnissen entspricht.

Ich will deine Fähigkeiten nicht anzweifeln, aber könnte es sein, dass ein Fehler in deinem Programm die Probleme auslöst? ;)

Ergänzung:

new und delete in c++ greifen in der g++ STL auf die c-Funktionen malloc/free etc. zu. Probleme bei der STL sind mit Strings zu erwarten, da diese copy-on-write einsetzen und diese Mechanismen nicht Threadsafe implementieren (Siehe dazu älterer Thread "Threadsafe C++ stdlib (http://www.mrunix.de/forums/showthread.php?s=&threadid=33243)"). Abhilfe schaffen moderne Bibliotheken wie Bochs (http://bochs.sourceforge.net/).

Gruss, Andy

[amiga]

hmm,

es kann immer sein dass man irgendwo einen Fehler übersieht. Aber es ist schon merkwürdig dass er immer im malloc-Aufruf abschmiert. Ich habe die mallocs erstmal sicherheitshalber atomar gemacht.

Der malloc()-Aufruf schmiert so jedenfalls schonmal nicht mehr ab.

[RapidMax]

Ich kann dir ein Liedchen singen von Signal 11 :D

Schau dir mal die Quellen von malloc an, also malloc.c. Darin ist ziemlich viel interessanter Kommentar. So braucht er intern für die Verwaltung 4 Byte pro allozierter Speicherblock. Wenn du diesen nun überschreibst, kann es sein dass der Fehler viel später auftritt. Aus diesem Grund kannst du ein Makro setzen, dass beim Debuggen hilft.

Gruss, Andy

[amiga]

alles klar, hab den bug gefunden :) und es war auch noch sowas doofes ;)

hab ne variable einmal zuviel gefreed *g* ...

das kommt wohl von diesem Idioten, der mich die ganze Zeit ziemlich genervt und abgelenkt hat. Er wollte Linux installieren... aber in eine Doku schauen wollte er nicht, und hat mich dauernd mit seinen Fragen genervt und vom Programmieren abgelenkt ;)