 | |
Need to replace Mutex Handle. Have questions.
Dotnet Framework (CLR) microsoft.public.dotnet.framework.clr
 |
| | Thread Tools | Search this Thread | Display Modes |
#1
 
| |||
| |||
|
Need to replace Mutex Handle. Have questions. -
05-17-2005
, 10:27 AM
#2
| |||
| |||
|
|
I am working in managed C++. I have a Mutex object in which I need to replace the Handle property with a new handle. The new handle is being constructed using Win32 CreateMutex call. I need to call the Win32 version in order to set the security descriptor for the mutex, which is not natively supported in .NET Framework 1.1. I always get a little nervous about resource leaks when trying to bridge Win32 with .NET, so I want to make sure there is not the possibility of calamity here. The following code is a snippet of one of the managed class methods that I am using to return a Mutex object with the replaced handle. Will the new handle be released by the finalizer of the Mutex object, or do I have to do this manually? Also, I am not even sure if the code below will work. Can someone verify please? |
ought to be fine. The Handle property of System.Threading.WaitHandle gives
full transparent read/write access to the underlying handle, so when you
assign to the Handle property you're really changing the underlying handle.
You do need to close the old handle value, which you're doing, so I'd say
you're A-OK.
-cd
#3
| |||
| |||
|
|
Ken Varn wrote: I am working in managed C++. I have a Mutex object in which I need to replace the Handle property with a new handle. The new handle is being constructed using Win32 CreateMutex call. I need to call the Win32 version in order to set the security descriptor for the mutex, which is not natively supported in .NET Framework 1.1. I always get a little nervous about resource leaks when trying to bridge Win32 with .NET, so I want to make sure there is not the possibility of calamity here. The following code is a snippet of one of the managed class methods that I am using to return a Mutex object with the replaced handle. Will the new handle be released by the finalizer of the Mutex object, or do I have to do this manually? Also, I am not even sure if the code below will work. Can someone verify please? I didn't try it, but looking at the .NET 1.1 source code, it looks like it ought to be fine. The Handle property of System.Threading.WaitHandle gives full transparent read/write access to the underlying handle, so when you assign to the Handle property you're really changing the underlying handle. You do need to close the old handle value, which you're doing, so I'd say you're A-OK. -cd |
#4
| |||
| |||
|
|
Well, I tried this out, but something doesn't seem right. When I assign the Mutex->Handle value to a Win32 HANDLE type, the value of the Win32 handle is always <undefined> when I look at it in the debugger. I have even tried type casting it to an INT *, and it comes out as 0. Yet, when I inspect the Mutex->Handle value, it is a positive number. I don't understand what is going on here with the IntPtr. Also, when I try to assign a new value the Matrix->Handle, and I inspect it in the debugger, it still shows the old value. I may be getting confused by the behavior of IntPtr and how the debugger shows the output. Could you please clarify this behavior of IntPtr? |
debugger bug to me. Perhaps someone else knows.
Other than the oddness in the debugger, does the mutex appear to behave as
you expect?
-cd
#5
| |||
| |||
|
|
I am working in managed C++. I have a Mutex object in which I need to replace the Handle property with a new handle. The new handle is being constructed using Win32 CreateMutex call. I need to call the Win32 version in order to set the security descriptor for the mutex, which is not natively supported in .NET Framework 1.1. I always get a little nervous about resource leaks when trying to bridge Win32 with .NET, so I want to make sure there is not the possibility of calamity here. The following code is a snippet of one of the managed class methods that I am using to return a Mutex object with the replaced handle. Will the new handle be released by the finalizer of the Mutex object, or do I have to do this manually? Also, I am not even sure if the code below will work. Can someone verify please? static SECURITY_ATTRIBUTES SecAttr; static SECURITY_DESCRIPTOR SecDesc; Mutex *Utility::CreateOpenAccessMutex(BOOL InitialyOwn, String *Name, BOOL *CreatedNew) { Mutex *Ret = __gc new Mutex(); HANDLE OldHandle = (HANDLE) Ret->Handle.ToInt32(); CloseHandle(OldHandle); // Security settings must be explicitly set to allow full access to the mutex. InitializeSecurityDescriptor(&SecDesc,SECURITY_DES CRIPTOR_REVISION); SetSecurityDescriptorDacl(&SecDesc,TRUE,(PACL) NULL,FALSE); Ret->Handle = CreateMutex(&SecAttr,InitialyOwn, CString(Name)); if (GetLastError() == ERROR_ALREADY_EXISTS) { *CreatedNew = TRUE; } else { *CreatedNew = FALSE; } return Ret; } -- ----------------------------------- Ken Varn Senior Software Engineer Diebold Inc. EmailID = varnk Domain = Diebold.com ----------------------------------- |
Ret->Handle = CreateMutex(&SecAttr,InitialyOwn, CString(Name));
is invalid, you assign a void* to an IntPtr, you have to initialize a new
IntPtr using the void* value returned by CreateMutex like this....
Ret->Handle = IntPtr(CreateMutex(&SecAttr,InitialyOwn, ....
Willy.
#6
| |||
| |||
|
|
IMO This: Ret->Handle = CreateMutex(&SecAttr,InitialyOwn, CString(Name)); is invalid, you assign a void* to an IntPtr, you have to initialize a new IntPtr using the void* value returned by CreateMutex like this.... Ret->Handle = IntPtr(CreateMutex(&SecAttr,InitialyOwn, .... Willy. |
simple assignment should work.
Willy.
#7
| |||
| |||
|
|
Ken Varn wrote: Well, I tried this out, but something doesn't seem right. When I assign the Mutex->Handle value to a Win32 HANDLE type, the value of the Win32 handle is always <undefined> when I look at it in the debugger. I have even tried type casting it to an INT *, and it comes out as 0. Yet, when I inspect the Mutex->Handle value, it is a positive number. I don't understand what is going on here with the IntPtr. Also, when I try to assign a new value the Matrix->Handle, and I inspect it in the debugger, it still shows the old value. I may be getting confused by the behavior of IntPtr and how the debugger shows the output. Could you please clarify this behavior of IntPtr? There's no light I can shed on the subject really - it sounds like a debugger bug to me. Perhaps someone else knows. Other than the oddness in the debugger, does the mutex appear to behave as you expect? -cd |
#8
| |||
| |||
|
|
Well, I did a ToString() call on the Handle and it appears to have been changed properly. The problem must be with the debugger output when inspecting pointers. It seems to only want to show the value that the pointer points to rather than the actual value of the pointer itself. Maybe this is because of it running in the managed mode. |
IntPtr, and native HANDLE is defined as void*, it's really just an integer
index into a table - but there's really no way for the debugger to know
that.
-cd
|
« Previous Thread
|
Next Thread »
| Thread Tools | Search this Thread |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.