Que fait HeapLock(HANDLE handle) ? - Page 1

Quelle fait HeapLock pour verouiller un Handle ?
Est une operation lourde ?
Je voudrais savoir exactement comment opere cette fonction pour bien l'utiliser.

Actuellement dans ExtLiB, je verouille automatiquement le Heap de :
- toutes les arguments passes par indirections internes
- les variables utilisees par toutes les fonctions de Lecture, Ecriture, Affichage

J'ai lu quelque part qu'on ne peut pas prevoir quand le TIOS fait une reorganisation de la memoire.
Je voudrais savoir si :

1 - un 'Garbage Memory' ne se produira pas :
[PRE]
- a l'interieur d'une Fonction qui utilise de 'memset('
- a l'interieur d'une Fonction qui affiche uniquement des donnees d'un fichier
- a l'interieur d'une Fonction qui recopie les bytes d'une variable dans une autre
[/PRE]

1 - un 'Garbage Memory' est susceptible de se produire :
[PRE]
- a l'interieur d'une Fonction qui depose des donnees dans la pile ( car il me semble qu'elle peut s'etendre automatiquement )
- lorsqu'on alloue de la memoire
-
[/PRE]

Je crois qu'un lock est un simple flag dans la table des HANDLEs.

andoh_wilfried :
J'ai lu quelque part qu'on ne peut pas prevoir quand le TIOS fait une reorganisation de la memoire.

En fait, ce que tu sais c'est quelle fonction peut provoquer une réorganisation. Ce que tu ne sait pas, c'est si elle va être effectivement faite ou pas.
En fait, cela ne peut arriver que quand tu alloues ou realloue de la mémoire, ce qui implique aussi les appels de fonctions qui alloue elle-même de la mémoire. Je crois que dans la doc, c'est précisé.

En effet c'est un simple flag.
Un simple malloc provoque le lock du handle que tu utilises, je crois, de mémoire.

heu t'es sûr de ça ? ça pourrait poser pas mal de problèmes lors d'un realloc d'une taille plus importante par exemple, donc j'ai des doutes (flemme de vérifier).

De mémoire aussi, malloc lock les handles.
Sinon ça poserait d'autres problèmes puisqu'il faudrait mettre à jour tous les anciens pointeurs après chaque nouveau malloc pour peu qu'un tassement de tas ait lieu.

il s'en occupe pas de façon interne de ça ? (de ne pas déplacer les pointeurs des mallocs, vu qu'il les a tous en mémoire ça doit être possible)
après vérif, la doc de tigcc ne semble pas parler de locks à propos de malloc, mais c'est pê un oubli ou alors j'ai pas cherché où il fallait ^^

me semble que HeapAllocPtr locke effectivement
(sinon, en effet, les pointeurs deviendraient invalides n'importe quand)
et malloc est rien de plus qu'un alias

sisi, un malloc lock le HANDLE. C'est quasi obligatoire étant donné que le malloc te renvoie un pointeur. Et donc un realloc le delock avant d'essayer de l'agrandir.
edit : oups, un train de retard ^^

ui nan mais cf ce que je viens de dire, il pourrait aussi ne jamais le déplacer mais sans avoir besoin de faire un lock explicite dessus (simple supposition, je sais pas du tout comment ça marche et la doc n'a pas l'air d'en parler)

Zephyr :
il s'en occupe pas de façon interne de ça ? (de ne pas déplacer les pointeurs des mallocs, vu qu'il les a tous en mémoire ça doit être possible)
après vérif, la doc de tigcc ne semble pas parler de locks à propos de malloc, mais c'est pê un oubli ou alors j'ai pas cherché où il fallait ^^

Nan, il n'a pas les pointeurs en mémoire, juste les handles. Chez TIGCC, malloc est juste une surcouche de HeapAlloc(High en fait).

Zephyr>ce que tu proposes comme autre solution revient exactement aux même que de locker un HANDLE : mémoriser quelque part qu'il faut pas bouger un bloc de mémoire.

Ximoon
: Nan, il n'a pas les pointeurs en mémoire, juste les handles. Chez TIGCC, malloc est juste une surcouche de HeapAlloc(High en fait).

Ah oui exact j'oubliais le systeme des handles donc amarche pas ^^

hibou > heu ... oué merci, j'ai expliqué la différence juste un peu plus haut

ha ? bon vais me coucher

Merci pour tous ces eclairciements. En fait j'ai fait des 'HeapLock(' inutile dans les fonctions :
-'copy(' pour dest, srce
-'write(' pour dest, scre
-'read(' pour srce
- et toutes les autres fonctions d'ecritures dans les variables.

Juste parceque je pensait que l'Estack pouvait s'etendre automatiquement.

Sinon y a du nouveau dans ExtLiB :

- j'ai rajoute 2 bytes apres la taille du fichier contenant une LIST|MAT pour sauver les dimensions

- je suis en train d'Indexer la table contenant les noms des fonctions pour accelerer la recherche
J'utilise le code ascii de 1er lettre ( je vais surement essayer avec les 2 1er pour faire plus precis)
du nom de la fonction comme pour determiner l'Index a partir duquel commence la recherche dans
la table des fonctions. Si vous connaissez une meilleur methode pour index..............

suivant le nombre de fonctions, et si tu te fiches qu'un nom de fonction inconnu soit interpreté comme une fonction existante, tu peux utiliser une tache de hachage pour trouver rapidement ton index.
vertel calculait l'index à partir du nom de la fonction, ça explique pourquoi chaque nom ne faisait que 4 lettres (du coup l'index était forcément unique à chaque fonction, donc aucune ambiguité possible)

Euh je suis pas en info, juste en eco .
tu peux traduire une table de hachage STP

voici ce que je fait pour le moment :

//Table pour les lettres alphabetiques : 0 represente les lettres non utilisee
// le dernier Index est celui de 'z' 
unsigned char AlphaIndexTable[] = {
   0,
   6,
   7,
   14,
   17,
   20,
   22,
   23,
   0,
   0,
   26,
   28,
   32,
   41,
   44,
   49,
   57,
   58,
   64,
   85,
   0,
   92,
   96,
   0,
   0,
   99};
  short StartIndexSearch = AlphaIndexTable [ (*(unsigned char *)FuncName) ]

en gros ça consiste à faire une fonction qui va convertir une chaine en un entier qui la "représente" le mieux possible, on appelle ça la fonction de hachage. l'idéal, c'est que pour chaque chaine elle retourne un entier différent, bien sûr ce cas est impossible mais il faut s'en approcher au maximum.

les entiers que t'auras eu de cette façon, en leur appliquant un modulo "taille de ton tableau de pointeurs de fonctions", vont te permettre de sauter directement à la fonction que tu voulais.

peut-être qu'avec un exemple ça sera plus clair, mettons cette fonction de hachage-là (très mauvaise, mais peu importe c'est pour l'exemple) :

int hash(char *str)
{
    int i = 0;

    while (*str)
        i += *str++;
    return i;
}

ensuite, disons que ta table de pointeurs de fonctions fait 16 cases; tu disposes de deux fonctions "aaa" et "bbb". leurs valeurs de hachage sont hash("aaa") = 291 et hash("bbb") = 294, dont le pointeur vers la fonction "aaa" se trouve à la case 291%16 = 3 de ton tableau, et celui de la fonction "bbb" à la case "294%16" = 6. l'utilisateur veut appeller "aaa", tu calcules hash("aaa")%16, tu trouves 3, tu as directement la fonction à appeller. si il veut appeller "ccc", tu calcules hash("ccc")%16 = 9, il n'y a rien à la case 9 du tableau, donc cette fonction n'est pas reconnue par ton programme.
il te restera ensuite à gérer les collisions (plusieurs chaines qui donneraient la même valeur de hachage, plus ta fonction est mauvaise et plus ça arrivera souvent), et les faux positifs (une chaine non reconnue qui donnerait la même valeur de hachage qu'une chaine connue, et qui pourrait donc appeller une fonction quand même)

Merci, je vais essayer de voir si j'arrive a faire mieux que mon Indexation par tableau interpose.

En clair faut que je cree une fonction
H : N^m -> I= {0,1,.., IndexMax }
Vecteur(m) -> H(Vecteur)

Oui Martial, C'est bien de la pile de passage des Arguments du TiOS dont il s'agit.
Je ne sais pas si la Pile est pointee par a7 en assembleur ( car je ne fait que du C)
mais je pense que nous parlons bien de la meme pile.


Puisque tu dit qu'elle ne s'etend pas toute seule, je n'ai donc pas besoin de verouiller
les variables du TIOS lorsque je fait simultanement l'une des operation suivante :
- lecture des bytes d'une variable et ecriture dans une autre
- lecture des bytes d'une variable et ecriture dans la Pile

---

Que se passe-t-il si la pile est pleine ( faut qu'a le faire expres de passe 16 en parametre a une fonction ) ?

andoh_wilfried
: mais je pense que nous parlons bien de la meme pile.

Non non. Tu parles de la pile d'expressions du TIOS et il parle de la pile des programmes (là où ils stockent leurs variables locales et les adresses de retour des fonctions).

Si l'Estack est plein il ne se passe rien de grave, tu ne peux juste plus rien faire de ce qui touche à l'estack, les fonctions te retourneront des erreurs (toutes les fonctions push_*, did_push_*, replace*, en gros tout ce qui rajoute des données dans l'estack).

(Pour renchérir mais demande confirmation : )
Moi ce que j'ai cru comprendre c'est que l'estack n'est rien d'autre qu'un handle "spécial", et que donc, une fois sa taille max atteinte (65520 octets) le tios n'est pas capable d'en créer un deuxieme. Et que donc une fois plein, ben il est plein (FpgForce : en complement a ton post... )

Dude > à ma connaissance, c'est ça. Mais bon, faut pouvoir les remplir les 64ko

Merci Flanker ^^ Clair qu'il en faut pour les remplir

C'est pourtant tres simple de les remplir les 64K

Non rien ^^