Threading locks with remoting

[greg.merideth]

I have a project where we have a windows service that creates a
remoting object for an external client application to communicate with
using ipc. We've discovered the client is making updates to the class
fields by calling the update methods in the remoting object class and
while thats not an issue I'm curious about threading with remote calls.

I can't find much in the way of what threading issues can occur. If
the service's thread (which instantiates the remoting class) calls
method A() through a proxy class attained through
Activator.GetObject() while the client calls method A(). Does the
proxy class returned by Activator.GetObject have any thread safety to
it, being that it's dealing with two objects (client and server) that
are possible callers, or do I need to add my own thread safety code to
the class?

Is it possible to lead to a deadlock via a remote call and if so would
the remote call ever terminate or would that lead to a system issue
requiring a reboot?

 

[Nicholas Paldino [.NET/C# MVP]]

Greg,

I would imagine that the proxy itself would be thread-safe. I can't
guarantee this, but I would imagine that the proxy is just sending messages
to the server, which doesn't require a good deal of shared state (at least,
updating it at the same time).

However, on the server side, if you are using a singleton instance, then
you have to worry about thread safety on the instance that is created.
That's where you will have to pay attention.

Hope this helps.

 

[greg.merideth]

Testing showed us that the proxy code coming from multiple clients can
call the same remoted method with no thread safety and cause issues, so
I converted the remoted class to a singleton instance.

We managed to instance the remoted class in the server and get local
access to it's members via activator.getobject while getting another
instance lock using the client. Twice we were able to cause a stack
fault in the windows service (the server) by getting a deadlock. The
clients exception catch never even fired, the application simply died.

..NET 2 was nice in catching the lock from within the service and
brought me to the calling code in vs2005 which is a lot better than
what vs2003 was able to do for me.