nattch, le nombre de process qui attachent un segemnt, est géré auto par le système POSIX. ce qui lui permet d'effacer auto un segment quand il n'est plus utilisé si tu en a fait la demande par RMID (car laisser un segment sans proc peut être voulu aussi, et c'est aussi possible si tu ne fais pas de RMID).
T'as pas compris le probleme :
Processus A fait des allocations dans le segment X
Comment est-ce que le processus A peut savoir que toutes les allocations faites dans le segment X ont ete liberees ? (histoire de pouvoir liberer le segment sans tout faire planter)
Il ne peut pas a moins de faire du resource tracking, ce qui est couteux et ajoutes de la complexite au code.
C'est simple: un thread qui utilise par inadvertance une variable privée d'un autre thread ne fait pas crasher l'appli: c'est un bug silencieux et très pervers.
Oui c'est un bug silencieux et pervers, mais je suis pas sur que la complexite supplementaire du code causee par l'architecture segments de memoire partagee introduise moins de bugs que l'architecture avec des threads
[^] # Re: vs POSIX shared memory,pointeurs,RMID,spin
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
T'as pas compris le probleme :
Processus A fait des allocations dans le segment X
Comment est-ce que le processus A peut savoir que toutes les allocations faites dans le segment X ont ete liberees ? (histoire de pouvoir liberer le segment sans tout faire planter)
Il ne peut pas a moins de faire du resource tracking, ce qui est couteux et ajoutes de la complexite au code.
C'est simple: un thread qui utilise par inadvertance une variable privée d'un autre thread ne fait pas crasher l'appli: c'est un bug silencieux et très pervers.
Oui c'est un bug silencieux et pervers, mais je suis pas sur que la complexite supplementaire du code causee par l'architecture segments de memoire partagee introduise moins de bugs que l'architecture avec des threads