Re: Fast Multiple Application Comunication

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Yes .net
does support mutex's for thread synchronisation but this is a different
kind of implementation I believe it only allows access within the
application domain. Another kind of mutex can be used to access the
same object from many applications but I have not found a way to do
this in the .net framework. This is how Shared Memory works it creates
a named mutex of memory that can be accessed from many applications. I
think the reason that shared mutexs are not generally recomended is
that there is no guarantee that the mutex you are connecting has the
same structure.

Your assumptions on mutex are incorrect.

A mutex is an OS level locking mechanism ... nothing more ... It is
generally used to synchronize seperate processes. Think of it like a Monitor
(i.e. lock() { }) that can be used through multiple applications.

A mutex is used to synchronize access to global resources (like a shared
file or shared memory). It does not contain any real storage itself.

As for not having the "same sata structure", a mutex will always be a mutex,
this issue may apply to the shared resource but the same issue would apply
to any shared resource (I can easily connect a mail client to a server it
doesn't understand how to deal with and it will not work very well).

Cheers,

Greg Young
MVP - C#


"Olie" <owaits@xxxxxxxxx> wrote in message
news:1147432292.133503.215260@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Yes that is a good point about the number of clients. The requirement
is for up to 20 clients which is relatively small. A broadcast method
would be fine but I do need to ensure that any message gets to all the
clients.

Correct me if I am wrong Greg but I do not believe that I did leave out
Shared Memory or Shared Files as I think Shared Mutex is a lower level
abstraction on Shared Memory and Pipes is an implementation of Shared
Files. I should have maybe elaborated on the Mutex a bit more (cause of
much confusion and I do not profess to have got it correct). Yes .net
does support mutex's for thread synchronisation but this is a different
kind of implementation I believe it only allows access within the
application domain. Another kind of mutex can be used to access the
same object from many applications but I have not found a way to do
this in the .net framework. This is how Shared Memory works it creates
a named mutex of memory that can be accessed from many applications. I
think the reason that shared mutexs are not generally recomended is
that there is no guarantee that the mutex you are connecting has the
same structure.

Thanks Steve, I was definately leaning towards Named Pipes I just
wanted to see if there was a solution to be found that is built into
the .net framework. I am slightly confused that Micrsoft did not think
of the need for fast comunication when developing the framework.



.

Relevant Pages

  • Re: Fast Multiple Application Comunication
    ... Yes that is a good point about the number of clients. ... Shared Memory or Shared Files as I think Shared Mutex is a lower level ... this in the .net framework. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Fast Multiple Application Comunication
    ... I should add that shared resources such as shared memory and files while ... if there are machine boundaries ... Shared Memory or Shared Files as I think Shared Mutex is a lower level ... this in the .net framework. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: How to implement synchronous rpc between 2 processes on the same machine.
    ... DOORS(it is a properietry and quite efficient IPC by SUN) ... there to just review this design and provide your much needed inputs. ... Multi-process shared memory impls need to think about misbehaving process.. ... non-blocking timed mutex in there. ...
    (comp.programming.threads)
  • Re: event driven paradigm
    ... This last paragraph sounds like you are confusing threads and processes. ... If you have a multi-process model, then the sockets or pipes with ... In contrast to your assumption of my "shared memory" ... creating a mutex per thread and signal the mutex to wake up each thread ...
    (comp.programming.threads)
  • Re: PTHREAD_PROCESS_SHARED on GNU/Linux
    ... a stock Linux kernel won't release the lock on behalf of the ... mutex, so you'd probably have to stop everything and re-initialize the ... shared memory if any process dies unexpectedly. ... If a process dies unexpectedly while holding a mutex, ...
    (comp.programming.threads)