Mutex not working for cross-process file locking

Question

5.00/5 (2 votes)

See more:

See approved solution below - because the file is being accessed from two different user spaces, the Mutex needs to be declared as Global. Thanks to Andreas for the solution!

=========================
OK, I have a log file that can be written to by multiple processes. I'm trying to protect it with a named Mutex, but I'm still occasionally getting "file is in use by another process" errors when trying to open the file and I can't understand why. As far as I can tell, I'm using the Mutex correctly. Any pointers would be greatly appreciated...

Relevant (simplified) code is below - this is in an assembly that is called by both processes, and I have verified that both processes believe that they are using the same Mutex by having one process create the Mutex and the other use OpenExisting.

C#

public class Log
{
  public static Mutex m_Mutex = new Mutex( false, "MyMutex" );

  public static void LogStuff( string stuff )
  {
    StreamWriter w = null;

    try
    {
      m_Mutex.WaitOne();

      w = File.AppendText( @"C:\temp.log" );
      w.WriteLine( stuff );
    }
    finally
    {
      if ( w != null )
      {
        w.Flush();
        w.Close();
        w = null;
      }

      m_Mutex.ReleaseMutex();
    }
  }
}

Other (possibly) important notes:
- This is currently happening in Debug mode from VS2008, where I am debugging only the main process.

- There are exactly 2 processes that can access the file, both of which are running on the same machine. The need for 2 processes has to do with some 3rd-party drivers that require Admin privileges, while we want the main application to run as the current user, even if they don't have Admin rights.

Posted 26-Mar-13 9:15am

tzych

Updated 27-Mar-13 2:39am

v3

Add a Solution

Comments

Paulo Zemek 26-Mar-13 15:44pm

Are you accessing the file from many processes in the same computer? Or are you acessing the file from the network?

tzych 26-Mar-13 16:04pm

Paulo - the file is accessed from exactly 2 processes on the same computer.

Zoltán Zörgő 26-Mar-13 15:58pm

Debugging might mislead you in a multithreaded situation. As I see, it should work. Even NLog is using the same approach: http://svn.nlog-project.org/repos/nlog/trunk/src/NLog/Internal/FileAppenders/MutexMultiProcessFileAppender.cs

Paulo Zemek 26-Mar-13 16:29pm

Well... so, if there is no one else reading the file... I simple don't know... the code seems fine to me.

CHill60 26-Mar-13 17:08pm

I may be way off base here but is this assembly a singleton?

tzych 26-Mar-13 17:26pm

The Log class/assembly is intended to be a singleton, yes. But that only works within a single process; with two different processes, you have two instances of the 'singleton'.

Sergey Alexandrovich Kryukov 26-Mar-13 17:29pm

First, why a mutex, not a lock statement. From what I know, only an upgradeable mutex has extra features over the lock.
You might say that the mutex is needed to make the lock named, but why named mutex then? The mutex should only be named for IPC, not inside the single process.

(OK, I see that you are using it in two processes. What the other process does? Calling Log.LogStuff, or something else? Just checking — your code looks fine to me.)

Can you also describe the problem in detail, more exactly?

—SA

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Andreas Gieriet · Accepted Answer · 2013-03-26T12:45:00

Solution 1

Change your code as follows:
1) Give the Mutex the name @"Global\MyMutex".
2) Call Dispose() on w after (or instead of) Close().
Do the same for your other process.

[EDIT]
I would simplify the code as follows:

C#

public class Log
{
  public static Mutex m_Mutex = new Mutex( false, @"Global\MyMutex" );
 
  public static void LogStuff( string stuff )
  {
    try
    {
      m_Mutex.WaitOne();
      using(var w = File.AppendText( @"C:\temp.log" ))
      {
        w.WriteLine( stuff );
      }
    }
    finally
    {
      m_Mutex.ReleaseMutex();
    }
  }
}

This using block calls the Dispose at the end of the block (thus, flushing and closing the stream and releaseing the proxy object of the file on the file system).
[/EDIT]

Cheers
Andi

Posted 26-Mar-13 12:45pm

Andreas Gieriet

Updated 26-Mar-13 13:05pm

v2

Comments

SoMad 26-Mar-13 19:47pm

I hope the OP replies to this to tell us if it solved the problem. I recall having a similar issue and coming to the conclusion that the OS had not completely released the file handle. If your Dispose solution takes care of that, it is much better than the loop I had to add, checking the status of the file before releasing the Mutex (or was that before opening the file).
I am looking through my projects, but I don't remember exactly where it was.

Soren Madsen

Andreas Gieriet 26-Mar-13 20:12pm

Use this program and run it concurrently on two consoles by giving two differeing arguments to distinguish the log file entries:

using System.IO;
using System.Linq;
using System.Threading;

namespace GlobalMutex
{
    class Program
    {
        public static Mutex m_Mutex = new Mutex( false, @"Global\MyMutex" );
        static void Main(string[] args)
        {
            string inst = args.Length > 0 ? args[0] : "";
            foreach (int i in Enumerable.Range(0, 1000))
            {
                try
                {
                    m_Mutex.WaitOne();
                    using (var w = File.AppendText(@"C:\Temp\Temp.log"))
                    {
                        w.WriteLine("{0}: {1}", inst, i);
                    }
                }
                finally
                {
                    m_Mutex.ReleaseMutex();
                }
            }
        }
    }
}

The result does not throw any exceptions.
Cheers
Andi

SoMad 26-Mar-13 20:38pm

My code is in C++ somewhere in one of our MFC projects. As I recall, one process was receiving streaming video over a TCP connection and storing it to a file, while the other process was waiting for the file to be closed with the valid video.
In other words, many megabytes had to be flushed to the file. Your sample code probably still works with large files, but the only way of knowing for sure is to try it out.

Soren Madsen

Andreas Gieriet 27-Mar-13 16:06pm

As Leandro stated below, the key is the Global Mutex and not the disposing. I went into reflector and saw that Close() and Dispose() can be exchanged for that particular stream class. I assume a global mutex would do for native Windows programs too, e.g. have a look at CreateMutex function (C++).
Cheers
Andi

SoMad 27-Mar-13 16:13pm

Then it was not the same problem as I had. It just rang a bell when I read it.
In any case, the solution works and I believe I gave you 5 yesterday, but let me double-check.

Soren Madsen

Andreas Gieriet 27-Mar-13 16:20pm

Thanks for the discussion anyways!
Cheers
Andi

tzych 27-Mar-13 8:37am

Changing the Mutex to Global seems to have done the trick! Thanks Andi!

Andreas Gieriet 27-Mar-13 16:01pm

You are welcome!
Andi

[no name] 26-Mar-13 21:54pm

I believe Andreas Gieriet's solution is the right one. However, there was no reason given in the solution to justify making the mutex a global mutex. I think the key is the point mentioned in the question where it says that one of the processes requires "Admin privileges". This is a pointer which directs us to think that the processes run under different user accounts. Thus, using a named mutex is not enough in this case, you'd need a [global] named mutex. That's why I think it is the right solution and I voted it a 5.

Don't just feed the man... teach him how to fish his own meal (or something like that).

Andreas Gieriet 27-Mar-13 15:58pm

Thanks for your 5!
You are right about what you say about feeding versus teaching. I gave too little explanation. Thanks for filling the gap. I'll try to give this more attention in the future.
Cheers
Andi

Sergey Alexandrovich Kryukov 3-Jun-15 21:11pm

Those words about feeding a fish are golden!
And by the way, My 5 for the answer, too.
And I hope you will like my own saying as well:
Feeding Apple or Why Don't We Answer Some Questions.
—SA

Andreas Gieriet 4-Jun-15 15:55pm

That's a good one! :-)
And thanks for your 5!
Cheers
Andi
PS: I was lately so busy - I hardly got time for CP... :-(