2010-11-27 19 views
2

Ignorer les problèmes multithreading, ce qui suit est garanti au travail:Vous cherchez avant de sauter

int can_alloc(size_t i) 
{ 
    void *p = malloc(i); 
    if(p == NULL) return 0; 
    free(p); 
    return 1; 
} 

// later 
if(can_alloc(10)) 
{ 
    char *c = malloc(10); // no need to verify, we already did? 
    memcpy(c, "something", 10); 
} 

Ceci est la plupart du temps par curiosité. Je n'ai pas l'intention de l'utiliser pour quelque chose, mais je crois qu'il devrait être garanti de travailler, et il serait instructif de savoir à coup sûr.

Répondre

5

Non. Même sans multi-thread, l'appel malloc permet d'obtenir des ressources (de mémoire) à partir du système d'exploitation. Habituellement (Windows, Linux, Mac, etc.) le système d'exploitation peut faire des choses qui affectent les ressources disponibles pendant que votre programme est en cours d'exécution - à tout moment. Cela signifie qu'entre votre chèque et votre allocation réelle, la mémoire peut devenir «indisponible».

Si vous avez exceptionnellement complet contrôle de l'OS, alors il pourrait être possible de rendre cela robuste - mais ce serait extrêmement difficile.

+0

Je pensais (dans la plupart des systèmes d'exploitation) que chaque processus avait une quantité de mémoire allouée à ce processus uniquement. –

+0

Je n'ai jamais entendu ça. Je pense qu'ils sont juste assignés ce qu'ils demandent (probablement arrondi à des tailles de blocs plus grandes). – sje397

+0

Oh. On dirait que je ne suis pas sur ma théorie OS. J'ai vérifié la norme et rien ne garantit cela, je vais donc dire que vous avez probablement raison. –

1

La réponse ci-dessus est correcte. Sur de nombreuses versions de Linux, c'est encore pire car il utilise une allocation de mémoire optimiste. Donc, même si malloc() renvoie non-nul cela ne pas signifie que la mémoire est vraiment disponible. Plus d'info here.

+0

La fixation est facile. 'echo 2>/proc/sys/vm/overcommit_memory'. Tout système qui doit être robuste aura cet ensemble. –