Named Win32 events

[Andrei]

Hi all!

I know how to use named Win32 events via Win32 API, but I
wanna use them via C# and .NET Framework - is there any
solution? AutoResetEvent and ManualResetEvent wrapper
classes don't provide this functionality, do they?

Thanks all!

 

[Jerry III]

Neil, named Win32 events are not messages, they're synchronization objects
much like AutoResetEvent and ManualResetEvent except they have a name (see
CreateEvent API function, it takes a name). That way you can open an
existing event by its name, even an event created by different process
without having to rig some sort of interprocess communication.

Unfortunately I don't know if .Net framework supports anything like this...

Jerry

 

[Mark Hurd]

Hi all!

I know how to use named Win32 events via Win32 API, but I
wanna use them via C# and .NET Framework - is there any
solution? AutoResetEvent and ManualResetEvent wrapper
classes don't provide this functionality, do they?

I was hoping your request would flush out a more definitive response, but this
thread:

http://groups.google.com.au/[email protected]&rnum=1

has me asking for confirmation that named Managed Mutexes can be safely
accessed cross-process and thus by unmanaged code.

Note that Brian Grunkemeyer [MS] in that thread states fairly clearly that
Managed code should only access Managed (wrappers for) synchronisation
objects, but he doesn't expand upon the opposite situation.

 

[Dave]

I haven't tried it myself but you should be able to p/invoke to the
unmanaged API and use the named synchronization primitives. You could also
try using the C# Mutex class to create a named mutex - I would expect it to
be visible to unmanaged mutexes.

 

[Mark Hurd]

I haven't tried it myself but you should be able to p/invoke to the
unmanaged API and use the named synchronization primitives. You could also

No, this is what has been generally advised against.

try using the C# Mutex class to create a named mutex - I would expect it to
be visible to unmanaged mutexes.

Yes, this seems to be the case, but we'd like some confirmation long-term...

 

[Dave]

also

No, this is what has been generally advised against.

It's been advised against primarily because of the CLR's inability to abort
unmanaged threads. If you absolutely, positively need interprocess
auto/manual reset events then currently there isn't much choice. I
personally would avoid it unless I absolutely needed it and no other
mechanism worked, especially if all the threads were managed threads.

Yes, this seems to be the case, but we'd like some confirmation long-term...

If it's supported in the current rev then use it - I don't believe it's
going to change anytime soon (too many other problems need to be solved). If
one day in the distant future they break it then you can devise another
means.