By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,916 Members | 1,305 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,916 IT Pros & Developers. It's quick & easy.

Mutex problem

P: n/a
Hi.

I want to use the same mutex in different classes (web pages in an ASP.NET
application). In global.asax.cs, the class that starts up first, I create a
Mutex like this:

static private Mutex mtxBezoeken = new Mutex(false, "bezoeken");

which compiles and executes just fine. Then in another page I want to write
to a file that may also be accessed by global.asax.cs so I want access to
the same mutex that will help me synchronize. In this other page class I
declare another Mutex object with an identical declaration. The idea is that
the system will look up any existing mutex with the id "bezoeken" and wrap
that in the Mutex object instead of creating a new system mutex. This is how
it is documented and what I am used to from Win32 programming.

However, when the second declaration is executed I get:

"System.ApplicationException: Access is denied."

It is obviously because the mutex already exists, when I change "bezoeken"
in the second declaration to a new unique id it executes fine. Of course
this would defeat the purpose of the second mutex.

I am not requesting ownership, I can't figure out what the problem is.

Martin.
Nov 15 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
I assume you are using some sort of impersonation in your ASP.NET
application. When your global.asax.ca routine is called it is called on a
thread with the worker process identity. This creates the mutex with the
default DACL for that identity (probably giving access only to that
identity, the local system and maybe administrators). Later, in your page,
the call to CreateMutex is executed on a thread with another identity that
does not have access to the original mutex so the call fails with an access
denied error.
"Martin Maat" <du***@somewhere.nl> wrote in message
news:10*************@corp.supernews.com...
Hi.

I want to use the same mutex in different classes (web pages in an ASP.NET
application). In global.asax.cs, the class that starts up first, I create a Mutex like this:

static private Mutex mtxBezoeken = new Mutex(false, "bezoeken");

which compiles and executes just fine. Then in another page I want to write to a file that may also be accessed by global.asax.cs so I want access to
the same mutex that will help me synchronize. In this other page class I
declare another Mutex object with an identical declaration. The idea is that the system will look up any existing mutex with the id "bezoeken" and wrap
that in the Mutex object instead of creating a new system mutex. This is how it is documented and what I am used to from Win32 programming.

However, when the second declaration is executed I get:

"System.ApplicationException: Access is denied."

It is obviously because the mutex already exists, when I change "bezoeken"
in the second declaration to a new unique id it executes fine. Of course
this would defeat the purpose of the second mutex.

I am not requesting ownership, I can't figure out what the problem is.

Martin.

Nov 15 '05 #2

P: n/a
"Stephen Martin" <sm*****@removethis.emsoft.andthis.ca> wrote in message
news:OI**************@TK2MSFTNGP12.phx.gbl...
I assume you are using some sort of impersonation in your ASP.NET
application. When your global.asax.ca routine is called it is called on a
thread with the worker process identity. This creates the mutex with the
default DACL for that identity (probably giving access only to that
identity, the local system and maybe administrators). Later, in your page,
the call to CreateMutex is executed on a thread with another identity that
does not have access to the original mutex so the call fails with an access denied error.
That doesn't make sense to me. Mutexes have identity-affinity? I always
considered them to be system-wide objects with the purpose of synchronizing
resource access regardless what thread, process or identity is requesting
it. Isn't that the whole idea?

Anyway, it seems you are right because when I try to do the same thing from
a single page:

static private Mutex mtxBezoeken1 = new Mutex(false, "bezoeken");
static private Mutex mtxBezoeken2 = new Mutex(false, "bezoeken");

it runs just fine.

So the Monitor class is fine if you don't need to go beyond the scope of a
single object, mutexes are fine if you don't need to go beyond the scope of
a single user, ... what do I use to address my little problem here?
Semaphores don't seem to exist in .NET (or would "InterLocked" cover that?).
There is not a lot of stuff on the net about mutexes and user identities.

Thanks for the first part of the solution.

Martin.

"Martin Maat" <du***@somewhere.nl> wrote in message
news:10*************@corp.supernews.com...
Hi.

I want to use the same mutex in different classes (web pages in an ASP.NET application). In global.asax.cs, the class that starts up first, I create
a
Mutex like this:

static private Mutex mtxBezoeken = new Mutex(false, "bezoeken");

which compiles and executes just fine. Then in another page I want to

write
to a file that may also be accessed by global.asax.cs so I want access

to the same mutex that will help me synchronize. In this other page class I
declare another Mutex object with an identical declaration. The idea is

that
the system will look up any existing mutex with the id "bezoeken" and wrap that in the Mutex object instead of creating a new system mutex. This is

how
it is documented and what I am used to from Win32 programming.

However, when the second declaration is executed I get:

"System.ApplicationException: Access is denied."

It is obviously because the mutex already exists, when I change "bezoeken" in the second declaration to a new unique id it executes fine. Of course
this would defeat the purpose of the second mutex.

I am not requesting ownership, I can't figure out what the problem is.

Martin.


Nov 15 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.