2017-07-20 11 views
0

Je dois créer un verrou nommé qui fonctionne correctement avec une application multi-thread pour Linux. Chaque instance d'application peut utiliser plus d'un verrou nommé avec des noms différents.Posix verrouillé inter processus de travail ce qui fonctionne avec l'application multi-thread?

Je connais fcntl/flock, mais cela ne fonctionne pas si vous essayez de verrouiller deux fois à partir d'un thread différent d'une application ou d'un thread.

Je sais environ open(..., O_CREATE | O_EXCL), mais ce verrouillage de fichier ne sera pas supprimé si l'application a été supprimée par le signal KILL ou a été plantée avec une erreur de segmentation et il est nécessaire de supprimer manuellement les fichiers de verrouillage après redémarrage.

Toute autre façon?

+0

Pouvez-vous s'il vous plaît partager plus d'informations? Un aperçu de code de la façon dont vous avez implémenté le verrou? – skr

+0

Communément, j'ai besoin d'implémenter la fonction '' int lock (const char * name) '' et 'int unlock (const char * nom)' qui fonctionne correctement avec une application multi-thread et une instance d'application différente. Si une application de thread ou d'instance demande deux fois 'lock', le second appel doit être refusé jusqu'à ce que la ressource ne soit pas déverrouillée avec l'appel' unlock'. Et si l'application était plantée, que le système d'exploitation devrait fournir un comportement comme la fonction 'unlock' a été appelée. – knst

+0

Une méthode pour gérer cela est de capturer le signal comme la segmentation, tuer et libérer tous les verrous et quitter. https://en.wikipedia.org/wiki/C_signal_handling – skr

Répondre

0

Si vous avez juste besoin de fonctionner sous Linux moderne, vous pouvez utiliser file-private locks. Si ce n'est pas une option, vous devrez construire votre propre abstraction de verrouillage thread-safe au-dessus des verrous fcntl. SQLite est du domaine public et a implémenté cela, vous pouvez donc regarder cela pour vous inspirer. Si le code GPL est correct: OpenJDK a une autre implémentation incompatible de la même chose.

O_EXCL ne fonctionne pas de verrouillage (au-delà de l'étape de création de fichiers), de sorte que est généralement pas utile.

Les autres options sont les sémaphores System V et POSIX, mais ceux-ci ne fonctionnent généralement pas aussi bien que les verrous fcntl lors du traitement des jours. Un mutex robuste, un processus partagé dans un mappage de fichiers pourrait être une option aussi bien, mais vous devez être prudent de rester dans la sémantique POSIX en ce qui sérialisation sur le disque est concerné (en gros, vous devez réinitialiser le mutex chaque fois que la l'application démarre à partir de zéro, après un redémarrage ou une mise à jour de libc).