Datenaustausch zwischen thread?

[hustbaer]

Naja, das ist nicht wirklich ein Problem. Der Speicher wird ja freigegeben wenn das OS den Prozess entfernt.

[SoIntMan]

@hustbaer sagte in Datenaustausch zwischen thread?:

Naja, das ist nicht wirklich ein Problem. Der Speicher wird ja freigegeben wenn das OS den Prozess entfernt.

ja aber er gibt in der VS console beim schliesen ein memory block an der nich freigeben wurde

[It0101]

@hustbaer sagte in Datenaustausch zwischen thread?:

Naja, das ist nicht wirklich ein Problem. Der Speicher wird ja freigegeben wenn das OS den Prozess entfernt.

Aber aus Entwicklersicht finde ich das dennoch irgendwie "unbefriedigend".

[Quiche Lorraine]

@It0101
Raymond Chen denkt darüber etwas anders:

When DLL_PROCESS_DETACH tells you that the process is exiting, your best bet is just to return without doing anything

[It0101]

@Quiche-Lorraine sagte in Datenaustausch zwischen thread?:

@It0101
Raymond Chen denkt darüber etwas anders:

When DLL_PROCESS_DETACH tells you that the process is exiting, your best bet is just to return without doing anything

1. Muss man den kennen?
2. Mir gehts hauptsächlich darum: Ein Experte weiß genau, wo er die Zügel etwas lockerer lassen kann. Weniger erfahrene können das nicht. Ich will nur vermeiden, dass von solchen Aussagen ein falsches Signal ausgesandt wird.

[hustbaer]

@SoIntMan sagte in Datenaustausch zwischen thread?:

@hustbaer sagte in Datenaustausch zwischen thread?:

Naja, das ist nicht wirklich ein Problem. Der Speicher wird ja freigegeben wenn das OS den Prozess entfernt.

ja aber er gibt in der VS console beim schliesen ein memory block an der nich freigeben wurde

Stimmt. Und da sollte man nicht anfangen das zu ignorieren, weil man sonst echte Leaks nicht mehr findet.

Egal. Shared memory Multithreading hat auch so seine Probleme. Ich bleibe dabei: es kommt drauf an was besser ist, und es gibt Fälle wo Kommunkation mittels Window-Messages das Mittel der Wahl ist. Probleme mit nicht freigegebenen "Kommunikationspuffern" kann man auch vermeiden indem man nur eine "es gibt was zum Updaten" Message schickt, und die neuen Daten in eine Membervariable steckt. Zugriff synchronisiert über eine Mutex. Ala

void Foo::threadFn() {
    while (true) {
        SomeData data = computeNewData();
        {
            std::lock_guard guard{m_updatedDataMutex};
            m_updatedData = std::move(data);
        }
        PostThreadMessage(m_mainThreadId, WM_MY_UPDATE_DATA, 0, 0); // <- look ma, no pointer
    }
}

void Foo::onMyUpdateData() { // handles WM_MY_UPDATE_DATA
    std::lock_guard guard{m_updatedDataMutex};
    m_data = std::move(m_updatedData);
}

Einer der Vorteile dieser Technik ist dass man sicher sein kann, dass sich m_data nicht während der Ausführung eines anderen Message Handlers ändern kann. Und das auch ohne dass man die Mutex die ganze Zeit über gelockt halten müsste. D.h. automatisch auch dass man die Mutex bei Zugriff auf m_data nicht locken muss. Das kann einem das Leben schon einfacher machen.

[hustbaer]

@It0101 sagte in Datenaustausch zwischen thread?:

@Quiche-Lorraine sagte in Datenaustausch zwischen thread?:

Raymond Chen

1. Muss man den kennen?

Muss nicht. Ergibt sich aber irgendwann von selbst wenn man genug Win32 Zeugs macht.

[SoIntMan]

@hustbaer sagte in Datenaustausch zwischen thread?:

Egal. Shared memory Multithreading hat auch so seine Probleme. Ich bleibe dabei: es kommt drauf an was besser ist, und es gibt Fälle wo Kommunkation mittels Window-Messages das Mittel der Wahl ist. Probleme mit nicht freigegebenen "Kommunikationspuffern" kann man auch vermeiden indem man nur eine "es gibt was zum Updaten" Message schickt, und die neuen Daten in eine Membervariable steckt. Zugriff synchronisiert über eine Mutex. Ala

das is gut, so werde ich es auch umsetzen;)

@hustbaer sagte in Datenaustausch zwischen thread?:

Stimmt. Und da sollte man nicht anfangen das zu ignorieren, weil man sonst echte Leaks nicht mehr findet.

ja genau deswegen bin ich da pingelig gewesen;)

[SoIntMan]

Jetzt habe ich noch ein "leak" :

Detected memory leaks!
Dumping objects ->
{16203} normal block at 0x02CF82A8, 0 bytes long.
 Data: <> hû=
Object dump complete.

0 bytes groß!? kann mir jemand sagen wie ich das intepretieen soll?:)

[hustbaer]

Naja man kann auch malloc(0) sagen. Ist voll OK. Gibt eine Adresse zurück die man dann wieder mit free freigeben darf -- aber sonst halt nix. Gibt ein paar Situationen wo man sich durch die Regel ein paar "if"s spart.

ps: Der Returnwert von malloc(0) darf NULL sein, selbst wenn noch genügend Speicher vorhanden wäre. Dadurch wird das Feature etwas weniger nützlich. Eine Implementierung darf malloc(0) aber auch so implementieren dass eine gültige Adresse zurückgegeben wird, die man bloss nicht dereferenzieren darf, weil sie ja auf einen "0 Byte Block" zeigt.

[SoIntMan]

@hustbaer sagte in Datenaustausch zwischen thread?:

Naja man kann auch malloc(0) sagen. Ist voll OK. Gibt eine Adresse zurück die man dann wieder mit free freigeben darf -- aber sonst halt nix. Gibt ein paar Situationen wo man sich durch die Regel ein paar "if"s spart.
ps: Der Returnwert von malloc(0) darf NULL sein, selbst wenn noch genügend Speicher vorhanden wäre. Dadurch wird das Feature etwas weniger nützlich. Eine Implementierung darf malloc(0) aber auch so implementieren dass eine gültige Adresse zurückgegeben wird, die man bloss nicht dereferenzieren darf, weil sie ja auf einen "0 Byte Block" zeigt.

ich habe tatsächlich an eine Stelle eine "new char[0]" gemacht... jetzt is das leak weg;) Ok Dachte wirklich. dass bei einem 0 byte großem buffer ein nullptr zurück kommt, aber wäre dann inkonsequent im verhalten:)

[hustbaer]

Bei new T[0] ist es glaub ich sogar garantiert dass nicht nullptr zurückkommt.