Lire des données partagées dans un gestionnaire de signal

Question

Je suis dans une situation où je dois lire un arbre de recherche binaire (BST) dans un gestionnaire de signal (SIGSEGV gestionnaire de signal, qui selon mes connaissances est par base de threads). Le BST peut être modifié par les autres threads de l'application.

Maintenant, comme un gestionnaire de signal ne peut pas utiliser des sémaphores, des mutex, etc. et ne peut donc pas accéder aux données partagées, Comment puis-je résoudre ce problème? Notez que mon application est multithread et fonctionne sur un système multicœur.

Answer 1

Vous ne devez pas accéder aux données partagées à partir du gestionnaire de signal. Vous pouvez trouver plus d'informations sur les signaux dans les articles suivants:

Linux Signals for the Application Programmer

The Linux Signals Handling Model

All about Linux signals

On dirait que la meilleure façon de traiter les signaux dans linux jusqu'à présent est signalfd.

Answer 2

En supposant que le SH ne peut pas accéder aux données partagées directement, alors vous pourriez peut-être faire indirectement:

1. ont une certaine variable globale que seuls les gestionnaires de signaux peuvent écrire, mais peut être lu d'ailleurs (même si seulement dans le même fil).
2. SH définit le drapeau lorsqu'il est appelé
3. Les threads interrogent ce drapeau lorsqu'ils ne sont pas en train de modifier le BST; quand la recherche est réglée, ils effectuent le traitement requis par le signal d'origine (en utilisant les synchronisations nécessaires), puis déclenchent un signal différent (comme SIGUSR1) pour indiquer que le traitement est terminé
4. Le signal SH pour ce signal réinitialise le drapeau

Si vous êtes préoccupé par le chevauchement des SIGSEGV, ajoutez un compteur au mixage pour garder une trace. (Hey, vous venez de construire votre propre sémaphore!)

Le maillon faible ici est évidemment le sondage, mais c'est un début.

Answer 3

Vous pouvez envisager mmap -d'un système de fichiers fuse (dans l'espace utilisateur).

En fait, vous serez plus heureux sur Gnu Hurd qui a un support pour external pagers

Et peut-être votre hack de la lecture d'un arbre de recherche binaire dans votre gestionnaire de signal peut souvent fonctionner dans la pratique, non portably et dans un noyau manière dépendant de la version. Peut-être que la sérialisation de l'accès avec des astuces non portables de bas niveau (par exemple, futexes et atomic gcc builtins) pourrait fonctionner. Lire le code source (spécifique à la machine) de NPTL, c'est-à-dire les routines pthread Linux actuelles, devrait aider.

Il pourrait probablement être le cas que pthread_mutex_lock etc sont en fait utilisables depuis l'intérieur d'un gestionnaire de signal Linux ... (car il ne fait probablement que futex et des instructions atomiques).

Answer 4

Je vois deux solutions tout à fait propres:

1. Linux spécifiques: Créez des signaux de manipulation de fil dédiés. Capturer les signaux en utilisant signalfd(). De cette façon, vous allez gérer les signaux dans un fil régulier, pas n'importe quel gestionnaire limité. Portable: Utilisez également un thread dédié qui dort jusqu'à la réception du signal. Vous pouvez utiliser un canal pour créer une paire de descripteurs de fichier. Le thread peut lire (2) à partir du premier descripteur et dans un gestionnaire de signal, vous pouvez écrire (2) dans le second descripteur. L'utilisation de write() dans un gestionnaire de signal est légale selon POSIX. Lorsque le thread lit quelque chose dans le tuyau, il sait qu'il doit effectuer une action.