Visual Basic - Using Nested Mutex's in a threaded application - Risks and Suggestions

Question

Good evening fellow stackers, I have a mutex and threaded related question about

// ¦ = Run one or the other per call to routine

|GROUP A|   GROUP B  |
| A & B GROUP MUTEX  |
|=======|============|
|A1 & A2¦ B1 & |B2|B3|
               |MUTEX|
               |==|==|
               |B2¦B3|

Situation

Is this situation safe or viable?

I have 5 sub routines in VB.NET and I can run them in 2 groups comprising of seperate subsets in an asynchronous threaded manner.

However, as the horribly rough text-o-graph above shows, the mutex's work on the subset B as well.

Logic

Group A and B have to wait for the eachother if the jobs have started on either - A & B GROUP MUTEX helps keep this in check.

Inside Group A both can routines begin concurrently (B would have to wait for both A1 and A2 to be complete).

Group B, with B1, B2 and B3 can run B1 at the same time as either B2 and B3 but B2 and B3 cannot run concurrently, hence the subset MUTEX check.

Update: @pstrjds made a good point with using Sync-locking instead: The reason I am using Mutex's and not Sync Lock is due to the fact that I need to make this process multi user safe as within the sub routines are a lot of SQL and data based operations which required the program to be locked whilst multiple SQL-Transactions are carried out on different databases across 3 different servers to update them concurrently and safely - transaction handling in SQL is done and working well hence the broken down psuedo-code. @pstrjds is correct in saying that this is using threads spawned off the one class, however within the subroutines it calls to a web service (part of Group B's work in B2 and B3) which updates a separate 3rd party server. </Wall-o-Text>

Psuedo-code

Unfortunately the exact code is rather long but I am using this structure:

Sub AGroup_Method()

    Dim bln_FirstInstance As Boolean

    Using objABMutex As New Mutex(True, "Global\AB_MutexLock", blnFirstInstance)
        If bln_FirstInstance Then
            //Start Threads for subroutine A1 And then A2
            StartThread_A1()
            StartThread_A2()
        Else
           //Post that Group A subroutine needs to wait for Group B
        End If
    End Using
End Sub

Sub BGroup_Method(Byval p_blnRunBTwo as Boolean)

    Dim bln_FirstInstance As Boolean
    Dim blnBGroup_FirstInstance As Boolean

    Using objABMutex As New Mutex(True, "Global\AB_MutexLock", bln_FirstInstance)
        If bln_FirstInstance Then
            //Do subroutine group B

            //Start B1
            StartThread_B1()

            Using objBGroupMutex As New Mutex(True, "Global\BGroup_MutexLock", blnBGroup_FirstInstance)
                If p_blnRunBTwo 
                    If blnBGroup_FirstInstance Then
                        //Wait for mutex from B3 and then run B2
                        StartThread_B2
                    End If
                Else 
                    If blnBGroup_FirstInstance Then
                        StartThread_B3
                    End If
                End If   
            End Using                     
        Else
           //Post that Group B subroutine needs to wait for Group A

        End If

    End Using

End Sub

Help!

What I would like to ask is if the mutex nesting is a possible problem, if it is bad practice whatnots and is there a better way of implementing this using a threaded system.

Answer 1

I don't think you are off the wall using a Mutex here, but if all of the code is in the same class and you are just spawning worker threads in that class (I am basing this off the pseudo-code you presented) you could get away with just declaring two objects and using SyncLock to handle the access. That should be more performative than using the Mutex (again assuming that all of this code is in the same class and the threads are launched from the class and you don't need inter-process serialization)

Dim abLock as Object = new Object()
Dim bLock as Object = new Object()

Sub AMethod()
    SyncLock abLock
    ' Do stuff here
    End SyncLock
End Sub

Sub BMethod(ByVal pInBTwo As Boolean)
    SyncLock abLock
        StartB1Thread()

        SyncLock bLock
            ' Do B2 or B3 stuff
        End SyncLock
    End SyncLock
End Sub

Edit: Added information about named mutex as per suggestion: If you are using a globally named mutex you can run into permissions issues if the user running the code has limited access (take for example running as a guest user). Another issue that comes into play is creating it with the proper MutexAccessRule so that another user can access it after it is created. Code sample in C#:

Mutex mutex = null;
bool exists = true;

// Using try catch since as far as I know there is no other way to check if
// a mutex exists, but to open it and catch the exception, this may be changed
// in .Net 4.0, I originally wrote this targeting 2.0
try
{
     mutex = Mutex.OpenExists(@"Global\MyMutexName");
}
catch
{
     exists = false;
}

if (!exists)
{
     SecurityIdentifer sid = new SecurityIdentifier(WellKnownSidType.WorldSid, null);
     MutexAccessRule rule = new MutexAccessRule(sid, MutexRights.FullControl,
         AccessControlType.Allow);
     MutexSecurity security = new MutexSecurity();
     security.AddAccessRule(rule);

     bool createdNew = false;
     mutex = new Mutex(false, @"Global\MyMutexName", out createdNew, security);
}

The above code will create a mutex that is not restricted to the user that created it, this is important if you are in a terminal services environment with multiple people running the same program at the same time. You may be okay restricting some of the permissions more than I did there (really I create it with almost no restrictions), but without that you can have person A create the mutex and person B throw an exception because they can't access the mutex created by person A.

Answer 2

Yes, it is a bad practice. I scanned the question a few times but I don't exactly feel informed well enough to give a good answer. That's a problem, if you can't easily explain your locking model and you've got trouble coming up with a good picture that makes it clear then it also becomes very difficult to reason about the number of possible state permutations.

Not being able to reason about all possible state permutations has a potentially very nasty runtime penalty. Deadlock.