Mon scénario: un serveur et quelques clients (mais pas beaucoup). Le serveur peut uniquement répondre à un client à la fois, ils doivent donc être mis en file d'attente. J'utilise un mutex (boost::interprocess::interprocess_mutex) pour ce faire, enveloppé dans un boost::interprocess::scoped_lock. Le fait est que si un client meurt de façon inattendue (c'est-à-dire qu'aucun destructeur ne s'exécute) tout en maintenant le mutex, les autres clients sont en difficulté, car ils attendent sur ce mutex. J'ai envisagé d'utiliser l'attente temporisée, donc si le client attend, disons, 20 secondes et ne reçoit pas le mutex, il va de l'avant et parle au serveur de toute façon.Comment devenir propriétaire d'un boost boosté :: interprocess :: interprocess_mutex?
Problèmes avec cette approche: 1) il le fait à chaque fois. Si c'est dans une boucle, en parlant constamment au serveur, il doit attendre le timeout à chaque fois. 2) S'il y a trois clients, et que l'un d'entre eux meurt en tenant le mutex, les deux autres attendent juste 20 secondes et parlent au serveur en même temps - exactement ce que j'essayais d'éviter.
Alors, comment dire à un client, "hey là, il semble que ce mutex a été abandonné, s'approprier"?
Si vous comptez sur les clients pour effectuer la synchronisation, vous le faites en arrière. Vous devriez vraiment réparer votre serveur afin qu'il puisse accepter plusieurs connexions, même si cela ne fait qu'attendre les autres connexions pendant qu'elles servent une à la fois. Cela vous permet de sortir la partie * interprocess * de l'équation. –
Fair point. Cependant, à l'origine, mon application avait été spécifiée comme ayant seulement un client à la fois - je n'ai découvert que récemment (comme aujourd'hui) qu'il pourrait y avoir plusieurs clients. J'ai essayé de le résoudre facilement, mais je suppose que je devrais trouver quelque chose de plus sophistiqué. –
Il semble que tout le mécanisme du mutex soit défectueux sans mécanisme de récupération. Souhaits de boost corrige ceci. – balki