Threads

Kenner des Problems schrieb:

Der Einwand ist doch sinnlos...

wir sind sowieso längst vom thema abgekommen.

secondsun schrieb:

ich habe ein kleines Problem.Ich habe 2 Threads mit CreateThread instanziert.
Thread 1: Sucht bestimmte Dateien auf einem Medium
Thread 2: Verarbeitet die bestimmten Dateien

Jetzt ist der Thread 1 sehr viel schneller als der Thread 2. Wie erreiche ich es, dass eine Art "Leitung" gelegt wird? Also Thread 1 schreibt durchgehend alles in einen Queue und Thread 2 holt sich die Daten aus dem Queue heraus und verarbeitet sie.

Die Aufteilung der Threads ist dann aber nicht sehr sinnvoll. Thread 1 ist dann z.B. nach 1 Minute mit suchen fertig und Thread 2 muss noch 10 Minuten verarbeiten.

Wenn die Threads hauptsächlich auf die Platte zugreifen machst du es wahrscheinlich nur langsamer als schneller, wenn immer wieder von anderen Stellen gelesen wird.

hustbaer

Kenner des Problems schrieb:

Ohne einem atomaren Zeigerswap geht es nicht.
Wenn man solch einen hat, ich nenne diesen Befehl einfach mal pswap(a,b) dann kann man das so machen (in allen Threads):

wenn man nur einen producer und nur einen consumer hat, dann reichen atomare lese- und schreiboperationen + barriers.

wenn man mehrere producer und/oder consumer hat, dann braucht man einen atomaren swap (mehrere consumer), oder sogar einen atomaren compare-and-swap. und barriers. ohne barriers geht schonmal nix. (ein atomarer swap/compare-and-swap ist meist auch eine full-barrier, aber nicht unbedingt auf jedem system.)

C0de4Fun

Hi,

hustbaer schrieb:

@C0de4Fun:

Deine "RemoveFromQueue" Funktion ist nicht wirklich korrekt.
Du solltest die Queue nicht angreifen, bevor du die CRITICAL_SECTION gelockt hast.
Nichtmal den pQueueFirst Zeiger.

also dann quasi so:

...
void* RemoveFromQueue(PQUEUE pQueue)
{
    PQUEUE_ITEM pTmp;
    void* pTmpContent = NULL;

    EnterCriticalSection(&pQueue->CritSection);

    pTmp = pQueue->pQueueFirst;

    if(pTmp)
    {

        if(pQueue->pQueueFirst == pQueue->pQueueLast)
        {
            pQueue->pQueueFirst = NULL;
            pQueue->pQueueLast = NULL;
        }
        else
            pQueue->pQueueFirst = pQueue->pQueueFirst->pNext;

        pQueue->uiItems--;

        pTmpContent = pTmp->pContent;
        free(pTmp);

    }

    LeaveCriticalSection(&pQueue->CritSection);

    return pTmpContent;
}
....

Danke war mir nicht bewusst, ist aber eig klar weil ja die Add Func pQueue->pQueueFirst veraendern koennte.

hustbaer schrieb:

Und was dein Kommentar in GetItemCount angeht: ja, auch hier ist es nötig die CRITICAL_SECTION zu locken.

Danke auch fuer diese Antwort ;).

Peace C0de4Fun

hustbaer

Das sieht schon besser aus, ja

Blue-Tiger

Zwar ein bisschen Offtopic, aber: habt ihr irgendwelche Literaturempfehlungen fuer Lockfree-Datenstrukturen?

Blue-Tiger schrieb:

Zwar ein bisschen Offtopic, aber: habt ihr irgendwelche Literaturempfehlungen fuer Lockfree-Datenstrukturen?

internet: http://www.pdf-search-engine.com/lock-free-pdf.html

Blue-Tiger

;fricky schrieb:

Blue-Tiger schrieb:

Zwar ein bisschen Offtopic, aber: habt ihr irgendwelche Literaturempfehlungen fuer Lockfree-Datenstrukturen?

internet: http://www.pdf-search-engine.com/lock-free-pdf.html

Tjo, nur was davon ist gute Lektuere und was kann ich mir schenken?

volkard

Blue-Tiger schrieb:

;fricky schrieb:

Blue-Tiger schrieb:

Zwar ein bisschen Offtopic, aber: habt ihr irgendwelche Literaturempfehlungen fuer Lockfree-Datenstrukturen?

internet: http://www.pdf-search-engine.com/lock-free-pdf.html

Tjo, nur was davon ist gute Lektuere und was kann ich mir schenken?

Für mich war alles gut. Erstmal die Definition von lock-free und wait-free, die ist fast überall drin, und siehe da, lock-free sagt ja gar nicht, daß alle Threads weiterlaufen. Dann die Messungen und siehe da, auf dem AMD waren sie gar nicht schneller als Mutexe. Sehen, daß der lock-free-code überall komplex ist. Sehen, daß praktisch immer CAS genommen wird. Lernen, daß CAS2 für refcounting nötig ist. Erkennen, daß lock-free gar nicht allgemein was Gutes ist, sondern nur in Ausnahmen deutliche Steigerungen bringt. Lernen, daß man lock-free writers durch zu viele Leser ersticken kann. Erkennen, daß wir da im Moment einen Hype haben, dem ich nicht nachlaufen sollte.

Mein vorläufiges Fazit: Lock-free ist gut, wenn die Anwendung danach ruft, aber dann sollte es auch eine an die Anwendung angepaßte Datenstruktur sein, und wenn die Datenstruktur an die Anwenung angepaßt wurde, ist lock-free oft nicht mehr nötig. Außerdem sind bei mir CAS und Mutex ähnlich schnell.

volkard schrieb:

Sehen, daß der lock-free-code überall komplex ist. Sehen, daß praktisch immer CAS genommen wird.

Sprechen, dass so nicht gehen.