Frage zu Effective C++ Item 10

Tankian

void * Airplane::operator new(size_t size)
{
    if(size != sizeof(Airplane))
        return ::operator new(size);

    Airplane *p = headOfFreeList;

    if(p)
        headOfFreeList = p->next;

    else
    {
        Airplane *newBlock = 
          static_cast<Airplane*>(::operator new(BLOCK_SIZE * sizeof(Airplane)));          

        for(int i = 1; i < BLOCK_SIZE-1; ++i)
            newBlock[i].next = &newBlock[i+1];

        newBlock[BLOCK_SIZE-1].next = 0;

        p = newBlock;
        headOfFreeList = &newBlock[1];
    }

    return p;
}

Meine Frage geht also drum, ob nicht daran etwas falsch ist,
wenn mehr Airplanes als BLOCK_SIZE erstellt werden.

Nehmen wir mal an wir erstellen grad das (BLOCK_SIZE-1)te
Objekt dann gilt ja p->next == 0. Somit wird also headOfFreeList
auf 0 gesetzt und automatisch beim nächsten Mal p auch.

Da p nun wieder ungültig ist, wird wieder Speicher dazuallokiert,
was ja ansich in ner Liste kein so großes Problem darstellt. Aber
die 2 Listen werden ja ned verbunden, denn irgendwo dazwischen is
immernoch ein next-Zeiger, der auf 0 zeigt

Gabs da irgendwo nen Denkfehler von mir ?

schonmal danke
für Hilfe

volkard

ok, dazwischen ist ein zeiger auf 0.
also es sind zwei listen.
wo ist das problem? keiner will ja anhand der next-zeuger duch die ganze(n) liste(n) durchlaufen. nur zum feigeben einzelner Airplanes reicht das doch so. allerdongs kann es sein, daß man keine ganzen blöcke freigeben kann. ok, ist wohl gar nicht vorgesehen, sowas zu machen.
es ist kein profi-allokator, sondern nur einer, der mal ein eigenes new und delete vormacht. ich hätte noch einen einfacheren gemacht.

Tankian

Danke für die Antwort.
Hat Klarheit geschafft

Was wären denn dann Ideen
für einen 'Profi-Allokator' ?

volkard

Tankian schrieb:

Was wären denn dann Ideen
für einen 'Profi-Allokator' ?

als arbeitstier ein binary buddy allocator und dahinter ein paar small object allocators sind glaub ich modern. gerne mit spezieltricks, wie leichtem versatz beim erzeugen von seiten der small object allocators in verschiedenen threads, um die cache lines getrennt zu halten, threadlokalen small object allocators und wenn möglich auch möglichst teile im buddy allocateo (vielleicht 1MB-blöcke) threadlokal halten. meine idee dazu wäre noch für 4k-seiten nen speziellen alloator zu machen und noch ein paar datenstrukturen anzubieten, die von 4k-seiten leben. evtl auch ne erweiterung, daß man solchen seiten nen refcounter zufügt oder normal allokiertem speicher ne funktion, die die größe des allokierten speicherberichs zur laufzeit zurückgibt, denn sowas geht nur richtig performant, wenn man den allocator selber gebaut hat.

Tankian

Ähhm .. Ok

Hab ich wenigsten wieder
nen Haufen Zeugs zu googlen.

greetz