Comment trouver ce Mutex en C# est acquis?

Comment puis-je trouver de mutex poignée en C# qu'un mutex est acquis?

Quand mutex.WaitOne(timeout) les délais d'attente, il retourne false. Cependant, comment puis-je trouver qu'à partir du handle de mutex? (Peut-être à l'aide de p/invoke.)

Mise à JOUR:

public class InterProcessLock : IDisposable
{
    readonly Mutex mutex;

    public bool IsAcquired { get; private set; }

    public InterProcessLock(string name, TimeSpan timeout)
    {
        bool created;
        var security = new MutexSecurity();
        security.AddAccessRule(new MutexAccessRule(new SecurityIdentifier(WellKnownSidType.WorldSid, null), MutexRights.Synchronize | MutexRights.Modify, AccessControlType.Allow));
        mutex = new Mutex(false, name, out created, security);
        IsAcquired = mutex.WaitOne(timeout);
    }

    #region IDisposable Members

    public void Dispose()
    {
        if (IsAcquired)
        {
            mutex.ReleaseMutex();
            IsAcquired = false;
        }
    }

    #endregion
}

Actuellement, je suis en utilisant ma propre propriété IsAcquired afin de déterminer si je dois libérer un mutex. Pas indispensable, mais plus claire, serait de ne pas utiliser une copie secondaire de l'information représentée par IsAcquired de propriété, mais plutôt de demander directement le mutex s'il est acquis par moi. Depuis l'appel de mutex.ReleaseMutex() lève une exception si il n'est pas acquis par moi.

(Par acquis état, je veux dire que le mutex est dans pas signalé état quand je suis posséder le mutex.)

(EDIT: j'ai ajouté IsAcquired = false; grâce à mattdekrey post.)

InformationsquelleAutor TN. | 2010-06-10
  1. 5

    Comme vous le constaté, il n'y a pas de représentants du public sur Mutex classe:
    http://msdn.microsoft.com/en-us/library/system.threading.mutex_members.aspx

    Il n'y a également pas de fonctions natives pour que:
    http://msdn.microsoft.com/en-us/library/ms686360%28v=VS.85%29.aspx

    Cependant, il y a quelques sans-papiers/fonctions non prises en charge en particulier dans ntdll.dll. Ils permettent d'accéder aux objets du système. Cependant, ces fonctions peuvent changer ou ne pas être disponibles dans les futures versions de système d'exploitation.

    Donc, la réponse est: Il n'est pas possible à l'aide de moyens conventionnels.

    InformationsquelleAutor lioil
  2. 13

    La raison, il n'est pas propre façon de le faire c'est parce qu'il n'est pas une bonne idée et la raison est parce que les conditions de course sont-très - facile à présenter lorsque vous comptez sur ce type de logique. Si vos besoins de conception de changer.

    Tout d'abord, vous ne devez pas acquérir un verrou dans un constructeur. Tourner cette classe dans une usine qui renvoie un initialisé correctement objet mutex. De cette façon, vous pouvez savoir si vous avez acquis le verrouiller ou pas.

    NE comptez PAS sur d'en Disposer à libérer les verrous, cette demande de blocage monté code qui est difficile à maintenir. Utiliser un try/finally bloc pour s'assurer qu'il est libéré.

    Délais d'attente sont un peu louche. Utilisez uniquement des délais d'attente lorsqu'il n'est pas l'acquisition du verrou peut être considérée comme normale de fonctionnement. Ne pas être en mesure d'acquérir le verrou est généralement un bug et simplement de l'éviter avec des délais d'attente cache le bogue. Si vous avez besoin de délais d'attente, pensez à utiliser un événement (peut-être AutoResetEvent), ce qui peut être plus approprié.

    • Karl - je suis d'accord avec toutes vos déclarations sauf le constructeur/disposer les pièces; Disposer n'est pas le même comme un destructeur - le à l'aide de l'énoncé est mis en œuvre par un try/finally bloc quand il s'agit de l'IL. (Comme indiqué ci-dessous, je pense que le constructeur serait bien si elle a TOUJOURS généré une exception quand il a échoué à acquérir le verrou pour garantir que la section critique ne s'est pas exécuté.)
    • Matt - msdn.microsoft.com/en-us/library/b1yfkh5e.aspx: "Ne supposez pas que Disposer va être appelé." Vous avez raison, tant que les devs portée dans un bloc using ou manuellement appeler dispose ce serait parfait. Mais c'est maladroit. Beaucoup de gens supposent un finaliseur (ou plus probablement n'en avons aucune idée...) et de laisser tomber hors de portée. Cela ne fonctionnera pas avec des serrures parce que le GC peut ou ne peut pas percevoir l'objet tout de suite, provoquant la folie dans le blocage. Il crée dur de trouver des bugs. Il fonctionnera, mais il ajoute: "la faire de cette façon" le processus de la surcharge d'un simple verrou. Le meilleur pour faire loi sur les serrures comme les serrures.
    • Hmm, je n'ai pas lu cela. Je me demande pourquoi ce n'est pas mentionné sur le IDisposable.Jetez page de documentation. +1 - je pense que le vôtre doit être considéré comme la réponse.
    • Karl, je ne peut pas comprendre correctement - si j'ajoute un Release() méthode qui vous permettra d'appeler Dispose(), qu'il sera ok? Ensuite, comment puis-je utiliser AutoResetEvent de synchroniser les processus?
    • Je suis en train de dire de ne pas utiliser de disposer de l'interface à tous. Ont une méthode statique qui crée le mutex objets dont vous avez besoin (modèle de fabrique). Utilisez ensuite ces mutex directement plutôt que l'enveloppant. Je m'ennuie de cité, il n'est pas un AutoResetEvent, c'est un EventWaitHandle. Vous pouvez créer ou d'attendre sur un événement système jusqu'à ce qu'un autre processus des signaux. Vous pouvez préciser quel est le problème que vous essayez de résoudre, je pense que vous pouvez obtenir de meilleures réponses.
    • Je suis désolé, j'ai peut-être un problème cérébral:) je ne comprends toujours pas:( Vous avez dit: "d'Abord, vous ne devez pas acquérir un verrou dans un constructeur.' Pourriez-vous fournir une justification pour qui? Depuis, il est semblable à des flux/fichiers. Les fichiers sont également utilisés pour l'inter-processus de verrouillage. Mon problème: j'ai un système où plusieurs processus exécute "au hasard" (fondée sur des événements externes). Je voudrais éviter de les exécuter en même temps. Ils sont donc à acquérir un verrou. (Mais si un processus a une difficulté qui fonctionne plus, le prochain processus d'attente doit signaler que, et de continuer sans tuer le processus verrouillé.)
    • 1) l'Acquisition de verrous dans un constructeur. Votre logique de nettoyage va se compliquer - il n'y a pas de bonne façon de libérer le verrou. Flux/Fichiers ne peuvent pas acquérir des verrous dans un constructeur. Vous pouvez être confus quant à ce qu'un verrou est et ce qu'il fait pour vous. 2) Ces types de problèmes sont difficiles à résoudre, et il va devenir un problème de maintenance. il est préférable d'écrire une application de service qui contrôle le processus ou écrire un service qui combine toutes les fonctionnalités des autres processus. Centrale de gestion est beaucoup plus facile à déboguer et à entretenir.
    • 1, Votre logique de nettoyage va se compliquer - il n'y a pas de bonne façon de libérer le verrou. - l'Appel de Release ou Dispose est simple. Ou quelle complication-vous y voir? 2, les Ruisseaux/Fichiers ne peuvent pas acquérir des verrous dans un constructeur. Non, mais ils sont l'allocation d'un système de poignée et. Quelle est la différence entre le verrouillage d'un fichier et de verrouiller un mutex? 3, la direction est beaucoup plus facile à déboguer et à entretenir. je ne peux pas être plus d'accord:) Centralisée par rapport à des systèmes distribués...
    • Je suis fortement contre suppression des verrous dans un bloc finally, parce que la plupart des développeurs de faire mal. Et de le faire correctement, c'est une grande douleur. Également de l'OMI, il n'est même pas possible avec la plupart des mutex classes - ils manquent de méthode de verrouillage (une méthode similaire à la object obj, ref bool lockTaken surcharge de Monitor.Enter). J'avais suggérons fortement d'utiliser un lock() bloc au lieu de cela, et si ce n'est pas possible, un using() bloc avec un objet d'assistance qui déverrouille dans son Dispose méthode. De cette façon, vous n'avez zéro (lock) ou un lieu (Défaire) où vous devez écrire le bon verrouillage/déverrouillage du code.

    InformationsquelleAutor Karl Strings
  3. 2

    Bien, ce n'est pas exactement ce que vous demandez, mais je pense que cela permettrait de résoudre votre problème: pourquoi ne pas simplement ajouter une gestion d'erreur spécifiquement pour l'exception qui se produit si le Mutex est acquis par quelqu'un d'autre?

    public void Dispose()
{
    if (IsAcquired)
        try
        { mutex.ReleaseMutex(); }
        catch (System.Threading.SynchronizationLockException)
        {
            //Handle the exception, assuming you need to do anything.
            //All other exceptions would still be passed up the stack.
        }
}
    • Oui, merci, aussi une solution, mais je suis en train d'essayer de résoudre le problème de "meilleure" façon, si c'est possible:)
    • À partir d'un point de vue sécurité, c'est la seule façon de prévenir une course à condition. Tout en vérifiant que vous pourriez faire dans un environnement multithread serait battu comme vous pourriez le faire la vérification dans le monde, alors le thread acquiert comme vous le communiqué de provoquer une exception. C'est probablement le plus sûr modèle.
    • Pas sûr. Depuis, je pense que l'utilisation de interprocessus de verrouillage entre les threads d'un même processus n'est pas une bonne idée. Ainsi, dans le cas où un thread acquiert un processus global de verrouillage lorsqu'un autre thread est juste de le relâcher, je veux lancer une exception.
    InformationsquelleAutor Mike U
  4. 2

    Pourquoi ne pouvez-vous pas utiliser Mutex.OpenExisting 

    try
{
    Mutex foundMutex = Mutex.OpenExisting("MyTestingMutex");

    //Found Mutex
    foundMutex.ReleaseMutex();
}
catch (System.Threading.WaitHandleCannotBeOpenedException)
{
    //  System.Threading.WaitHandleCannotBeOpenedException:
    //    The named mutex does not exist.
}

    MODIFIER

    Je devine que certains de cela.

    Il semble que vous essayez de développer une API. L'un des articles que vous offrez dans votre API est une InterProcessLock.

    Je vais supposer que vous êtes le partage d'une collection sur les threads et que vous utilisez le Mutex à assurez-vous qu'une opération sur un temps.

    using (InterProcessLock myLock = new InterProcessLock("LockMutex", TimeSpan.FromMilliseconds(100.0)))
{
    if(myLock.IsAcquired)
    {
        //I have control then I can delete, add to the collection.
    }
}

    Je voudrais revenir sur cette conception. Que faire si je n'ai jamais wraped InterProcessLock myLock = new InterProcessLock("LockMutex", TimeSpan.FromMilliseconds(100.0)) en aide? Jeter ne serait pas appelé. Que faire si l'utilisateur n'appelle jamais les Jeter à tous?

    Il n'y aurait abandonné Mutex

    De MSDN

    Attention
    Abandonné mutex indique souvent une grave erreur dans le code. Lorsqu'un thread s'arrête sans relâcher le mutex, les structures de données protégée par le mutex peut-être pas dans un état cohérent. Le prochain thread pour demander la propriété du mutex peut gérer cette exception et de procéder, si l'intégrité des structures de données peuvent être vérifiées.

    Si vous essayez de protéger vos utilisateurs, vous pouvez vouloir les aider en contrôlant le Mutex pour eux afin qu'ils aient jamais à vous inquiéter à ce sujet.

    Un exemple possible est

    public static bool PerformLockedProcess(Action process, string commonLockName, TimeSpan timeout)
{
    Mutex mutex = null;

    //Get the Mutex for the User
    try
    {
        bool created;
        var security = new MutexSecurity();
        security.AddAccessRule(new MutexAccessRule(new SecurityIdentifier(WellKnownSidType.WorldSid, null), MutexRights.Synchronize | MutexRights.Modify, AccessControlType.Allow));

        mutex = new Mutex(false, commonLockName, out created, security);

        bool acquired = mutex.WaitOne(timeout);

        if (acquired)
        {
            process();

            return true;
        }

        return false;
    }
    finally
    {
        //Make sure we do not abandon the Mutex
        if (mutex != null)
        {
            try
            {
                mutex.ReleaseMutex();
            }
            catch (ApplicationException)
            {
                //In case that failes
            }
        }
    }
}

    C'est une façon possible. Tout dépend de ce que le but est. Je ne voudrais PAS de relais sur l'utilisateur final à l'appel d'un Jeter depuis un Mutex est un système d'exploitation de construire. Et si le nom n'est pas unquie il pourrait en effet d'autres processus, en utilisant le même nom de mutex.

    • Pour quoi? C'est juste une vérification si le mutex existe. Pas de savoir s'il est acquis.
    • Merci pour l'astuce est que la transmission de fermetures est plus sûr à l'encontre des erreurs d'utilisation de IDisposable.Dispose ou personnalisé Release method.
    InformationsquelleAutor David Basarab
  5. 1

    Cela ne profite pas à l'affiche originale de la question, mais ici il va.

    Bien que je ne suis pas en désaccord avec d'autres posters sur la bonne utilisation de Mutex, j'ai eu une demande d'où j'avais besoin de tester si quelqu'un possède un mutex sans prendre possession de moi-même. Comme mentionné par d'autres, le seul moyen est d'utiliser un sans-papiers NtQueryMutant système d'appel de ntdll.dll. J'ai créé une méthode d'extension pour la classe Mutex qui peut être utilisée comme ceci:

            bool createdNew = true;
        var m = new Mutex(false, MutexName, out createdNew);
        if ( m != null)
        {
            int currentCount;
            bool ownedByCaller, abandonedState;
            if (m.TryQuery(out currentCount, out ownedByCaller, out abandonedState))
            {
                Console.WriteLine(string.Format("Created New: {3}, Count: {0}, OwvedByMe: {1}, Abandoned: {2}",
                    currentCount, ownedByCaller, abandonedState, createdNew));
            }
            m.Close();
        }

    Et ici est la mise en œuvre

    public static class MutexExtensionMethods
{
public static bool TryQuery(this Mutex m, out int currentCount, out bool ownedByCaller, out bool abandonedState)
{
currentCount = -1;
ownedByCaller = abandonedState = false;
try
{
var handle = m.SafeWaitHandle;
if (handle != null)
{
var h = handle.DangerousGetHandle();
MutantBasicInformation mbi;
int retLength;
var ntStatus = NtQueryMutant(
h,
MutantInformationClass.MutantBasicInformation,
out mbi, 
Marshal.SizeOf(typeof(MutantBasicInformation)),
out retLength);
GC.KeepAlive(handle); //Prevent "handle" from being collected before NtQueryMutant returns
if (ntStatus == 0)
{
currentCount   = mbi.CurrentCount;
ownedByCaller  = mbi.OwnedByCaller;
abandonedState = mbi.AbandonedState;
return true;
}
}
}
catch
{
}
return false;
}
#region NTDLL.DLL
[DllImport("ntdll.dll")]
public static extern uint NtQueryMutant(
[In] IntPtr MutantHandle,
[In] MutantInformationClass MutantInformationClass,
[Out] out MutantBasicInformation MutantInformation,
[In] int MutantInformationLength,
[Out] [Optional] out int ReturnLength
);
public enum MutantInformationClass : int
{
MutantBasicInformation
}
[StructLayout(LayoutKind.Sequential)]
public struct MutantBasicInformation
{
public int CurrentCount;
[MarshalAs(UnmanagedType.U1)]
public bool OwnedByCaller;
[MarshalAs(UnmanagedType.U1)]
public bool AbandonedState;
}
#endregion
}
    • J'ai ajouté un manque (obligatoire) GC.KeepAlive appel. Mieux encore serait de simplement déclarer NtQueryMutant d'utiliser un SafeWaitHandle paramètre.
    InformationsquelleAutor Leo
  6. 0

    .NET classe Mutex est originaire mutex wrapper, qui donne les mêmes possibilités, en tant que natif de mutex de l'API (à l'exception d'attente pour le nombre de waitable objets de type différent). Si vous souhaitez acquérir des mutex sans blocage, appel mutex.WaitOne(0). À l'aide de PInvoke, vous pouvez appeler WaitForSingleObject, avec le même résultat.

    • Merci, mais je ne veux pas d'acquérir le mutex si ce n'est déjà acquis. Est-il une fonction pour ça?
    • Non, il n'y a aucun moyen à la fois dans .NET mutex et de l'API native. Mutex peut être acquise que si il n'est pas acquis par une autre thread. Vous souhaitez peut-être besoin d'un autre type de synchronisation. Définir vos besoins, peut-être un autre type de synchronisation, comme événement ou sémaphore, les rencontre.
    • J'ai mis la réponse dans le post (depuis que ma réponse est plus long).
    InformationsquelleAutor Alex F
  7. 0

    Si vous êtes vraiment essayer de faire un inter-processus de verrouillage, comme son nom l'indique, vous voulez un moyen de détecter si le Mutex a été effectivement acquis de toute façon, c'est exact? Je ne suis pas sûr de savoir comment votre code qui utilise votre InterProcessLock serait assurée d'être verrouillé si il n'y avait pas IsAcquired de la propriété. (Aussi, pour se protéger contre les programmeurs qui, par erreur, appelez dispose deux fois, j'avais mis le IsAcquired à false dans votre Dispose méthode.)

    J'ai mis en place la même chose moi-même (parce que je préfère de beaucoup l'aide du bloc d'essayer, enfin, il suffit de libérer le mutex) et au lieu de cela a déclenché une exception lorsque le délai a été dépassé, ce qui, si je me souviens le projet correctement, ne pas appeler la méthode dispose.

    Edit:
    Avantage de jeter l'exception dans le constructeur: votre section critique est également complètement évités, et vous pouvez effectuer la gestion d'erreur dans les catch bloc, ce qui pourrait inclure le même appel de la méthode de votre section critique avait, de toute façon, même si personnellement, je considère qu'une mauvaise pratique.

    À la réflexion, plutôt que d'utiliser try ... catch comme indiqué dans une autre réponse, vous pouvez utiliser les éléments suivants sur votre disposer:

    public void Dispose()
{
if (IsAcquired)
{
lock (mutex) 
{
mutex.ReleaseMutex();
IsAcquired = false;
}
}
}

    Il se sent un peu ironique de lock un mutex, mais là vous l'avez. Alors que je suis totalement d'accord que vous ne devriez pas compter sur de Disposer d'être appelé en raison de la documentation de l'interface IDisposable, je pense qu'il est très pratique d'avoir un inter-processus en section critique indiquée par un using() { } bloc.

    • Si les programmeurs appel Dispose() deux fois, il va lever une exception. Donc, ils peuvent trouver qu'il ya un bug dans leur code. Plus tôt, j'étais aussi de lancer une exception dans le constructeur. Mais plus tard, j'ai changé, depuis les programmeurs peuvent décider, dans certaines situations, pour exécuter le code, même si la serrure n'est pas acquis. (Par exemple, il y a des processus indépendants et peut-être l'un est resté coincé, donc, la deuxième est en attente et alors, il sera exécuté en dépit de cela.)
    • La IDisposable conception de la documentation précise que "Si un objet de Rebut méthode est appelée plus d'une fois, l'objet doit ignorer tous les appels après la première. L'objet ne doit pas lever une exception si sa méthode dispose est appelée plusieurs fois." msdn.microsoft.com/en-us/library/...
    • +1 Ah, ok. Merci pour l'information. Je n'ai pas lu que:(
    InformationsquelleAutor Matt DeKrey