IPC Mutex under Window….Not recommended?

Question

0.00/5 (No votes)

See more:

Mutex –in windows- seems not to be a safe way to solve concurrency access.
Can anybody confirm this?

A mutex should be able to control access to any resources. In my case I use a named mutex, but windows seems not to be able to control this beyond sessions…even I use prefix “Globals\” for mutex name.

Problem:
A process will be started by a windows service. This process does create a mutex “Global\xyz”.
A second process started by myself by double clicking the exe in the explorer. This process also creates the mutex “Global\xyz”...successfully....what I do not expect...

Same behaviour in xp and W7.

Where I’m wrong? Any suggestions? Is it a windows bug?

Posted 19-Jan-14 5:40am

idle63

Add a Solution

Comments

CPallini 19-Jan-14 11:45am

Silly question: have you properly escaped the backslash in the mutex name?

[no name] 19-Jan-14 11:55am

Sorry I probably missunderstood your comment....very sorry!

CPallini 19-Jan-14 12:13pm

No problem.
hence you should write "Global\\xyz" and test it again.

[no name] 19-Jan-14 13:01pm

Of course in my c++ code I wrote "Global\\xyz", otherwhise it will not compile ;).
To be precise: My mutex name is the application exe name (Param(0)) from where I remove all "\" and preceed it with "Global\". You can trust, that I'm safe in these basics.

CPallini 19-Jan-14 13:15pm

I would compile. I would just issue a warning.
Of course I trust you :-)

[no name] 19-Jan-14 13:33pm

bcb6 will generate an error not only a warning...in case I write "Global\" instead of "Global\\". Error is something like "undetremined string constant".
Thank you very much for your help.

CPallini 19-Jan-14 15:32pm

NO much help, actually. Sorry. I guess there isn't actually a Windows's fault, because, otherwise you would find many many folks complaining of that. However I have no clue on what is happening on your system.

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)

KarstenK · Accepted Answer · 2014-01-19T07:05:00

Solution 1

check the error code with GetLastError() -> it should be ERROR_ALREADY_EXISTS
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682411(v=vs.85).aspx[^]

Posted 19-Jan-14 7:05am

KarstenK

Comments

[no name] 19-Jan-14 13:30pm

Thanks for this. Allready checked with GetLastError. For xp and W7 same unexpected behaviour, when first process has been started by a windows service.
[Edit]widows->Windows[Edit] greetings from "freud": http://en.wikipedia.org/wiki/Sigmund_Freud :)

SoMad 19-Jan-14 22:56pm

Can you clarify this? In my experience, KarstenK is correct. The return value is a handle to the existing mutex and GetLastError() returns ERROR_ALREADY_EXISTS just as documented[^]. It is then up to you to make you program behave 'correctly', whatever that is in the specific context of your application.

Soren Madsen

[no name] 20-Jan-14 3:31am

I agree, it should work in the way KarstenK described it. And this is also the case when I start the application by myself from the explorer. But as soon I start the first application from a service and the second from the explorer, both can create and own the mutex. Means vor both GetLastError return 0.

SoMad 20-Jan-14 12:03pm

That does sound weird. I also have projects where Windows services and applications access a mutex and I do not have the problem you are describing. In most of our cases (possibly all our cases), we are creating the mutex and applying a Security Descriptor in order to limit access to the mutex based on the logged in user's privileges, but I don't know if that would change the behavior.

Soren Madsen

[no name] 20-Jan-14 12:35pm

It is really a confusing thing:
- On XP one has to activate FUS (fast user switching) which is not available if the pc is in a domain. So here I made no further tests.
- On W7: Very surprising!!
My mutex name in real is not simply "Global\xyz". I create it from Param(0) (the exe path) and remove from Param(0) all backslashes. After a lot of trials I was near to give up and in my despair I made a last test, where I also removed ":" from the Param(0)....and.... I can not believe it now it works.
BTW: GetLastError does return ACCESS_DENIED for the second started process and not ERROR_ALREADY_EXISTS
Thank you for your help.

SoMad 20-Jan-14 12:44pm

If you got it working, that's great. If you have not already done so, I will recommend that you fire up Sysinternals - Process Explorer[^]. Go to the View menu and check "Show Lower Pane", then below that menu item got to "Lower Pane View" and select "Handles". Now you can examine details about the handles used by your applications and by right-clicking on your mutex handle, selecting Properties, going to the Security tab you can drill down to see the privileges users and groups have for accessing the mutex.

Soren Madsen

SoMad 20-Jan-14 13:20pm

BTW, now that you have sorted out the mutex issue, I should mention that we use COXInstanceManager from The Ultimate Toolbox[^] (free, hosted and maintained here at CodeProject). That class has several nice features, including passing command line parameters to an already running instance.
I couldn't say if it would solve your problem and if you don't already use the library it might be more work than you want to do to get it fully integrated into your project, but I thought I would mention it anyway.

Soren Madsen

[no name] 20-Jan-14 14:10pm

Thank you very much for this information. But I think for my present situation (borland builder c++ version 6) it will not help.

I will analize it with Sysinternals PE and give some feedback. Great hint ;)

Thank you very much, kind regards, Bruno

KarstenK 20-Jan-14 7:11am

And the name was "Global\XYZ" and REALLY the same???

Try it on another PC.

[no name] 20-Jan-14 9:34am

The names are REALLY the same and I tried it on xp/32 and W7/64.

It is really a confusing thing:

- On XP one has to activate FUS (fast user switching) which is not available if the pc is in a domain. So here I made no further tests.

- On W7: Very surprising!!

My mutex name in real is not simply "Global\xyz". I create it from Param(0) (the exepath) and remove from Param(0) all backslashes. After a lot of trials I was near to give up and in my despair I made a last test, where I also removed ":" from the Param(0)....and.... I can not believe it now it works.

BTW: GetLastError does return ACCESS_DENIED for the second started process and not ERROR_ALREADY_EXISTS

Thank you for your help.

KarstenK 20-Jan-14 10:05am

FUS can have some side effects on that theme. So watch out .-O

Sergey Alexandrovich Kryukov 28-Dec-14 12:32pm

If should not return this error. The process address space are isolated. Naming mechanism allows creation of separate objects in different processes, all representing the same system-global mutex. How else do you think IPC could work?

This error should returned only on attempt to create same mutex on the same process.

—SA