un lock qui génère un sigsev si tu passes outre
Qui a parlé de lock qui génère un sigsegv ?
J'ai surtout parlé de variables privées qui génèrent des sigsegv dans les cas des process concurents utilisant shm. Toutes les variables qui ne sont pas dans le shm, pour être précis, sont donc privées et protégées par sigsegv.
Quasiment tous les locks de synchronisation pour accéder à des zones mémoires partagées dépendent de la bonne volonté des parties en présence, puisque si la ressource est vraiment partagée, les parties peuvent y accéder sans faire appel à une fonction de lock, et donc passer outre cette fonction de lock. La seule exception notable étant les locks des fichiers, que personne n'est obligé d'utiliser. Et quand je parle de shm, j'en parle au sens large, pas seulement au sens de shm_open qui associe les shm à des fichiers. Il y a aussi shmget et mmap(MAP_ANONYMOUS) qui n'obligent pas à se servir de fichiers.
Bref:
Les futex sont utilisables pour les shm sans compromettre les variables privées des process (évidemment !) . Ils ont d'ailleurs été pensés pour ça:
"while the addresses for the same memory in separate processes may not be equal, the kernel maps them internally so the same memory mapped in differ-
ent locations will correspond for futex calls."
[^] # Re: vs POSIX shared memory, read-only
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Qui a parlé de lock qui génère un sigsegv ?
J'ai surtout parlé de variables privées qui génèrent des sigsegv dans les cas des process concurents utilisant shm. Toutes les variables qui ne sont pas dans le shm, pour être précis, sont donc privées et protégées par sigsegv.
Quasiment tous les locks de synchronisation pour accéder à des zones mémoires partagées dépendent de la bonne volonté des parties en présence, puisque si la ressource est vraiment partagée, les parties peuvent y accéder sans faire appel à une fonction de lock, et donc passer outre cette fonction de lock. La seule exception notable étant les locks des fichiers, que personne n'est obligé d'utiliser. Et quand je parle de shm, j'en parle au sens large, pas seulement au sens de shm_open qui associe les shm à des fichiers. Il y a aussi shmget et mmap(MAP_ANONYMOUS) qui n'obligent pas à se servir de fichiers.
Bref:
Les futex sont utilisables pour les shm sans compromettre les variables privées des process (évidemment !) . Ils ont d'ailleurs été pensés pour ça:
"while the addresses for the same memory in separate processes may not be equal, the kernel maps them internally so the same memory mapped in differ-
ent locations will correspond for futex calls."