WCF and Threading

  • Thread starter Thread starter Peter Larsen [CPH]
  • Start date Start date
P

Peter Larsen [CPH]

Hi,

I am testing some WCF behavior when running threads and i have a question
related to this.

The following code:

private void StartThread()
{
Console.WriteLine("Thread (StartThread): " +
Thread.CurrentThread.ManagedThreadId.ToString());

Uri tcpAddr = new Uri("net.tcp://localhost:4322/ServerTcpService");
Uri httpAddr = new Uri("http://localhost:12346/MyService2");

host = new ServiceHost(typeof(ContractClass), new Uri[] { tcpAddr,
httpAddr });
host.Open();

Console.WriteLine("Service host is open");
}

The code starts a WCF listener and if i run this from the mainthread, all
requests (from clients) are received in the same thread (the main thread).
Running the WFC in its own thread, each client is receievd in different
threads.

E.g. the mainthread runs in ID 10, the worker thread is running in thread ID
11.
Running two clients, the requests are received in thread ID 11 and 13.

Is this working by design ?

Running the WFC host in its own thread, makes the code more responsive, but
i'm not sure whether its ok to start the WCF listener in its own thread or
not. Is it ??

Best Regards
Peter
 
[...]
The code starts a WCF listener and if i run this from the mainthread, all
requests (from clients) are received in the same thread (the main
thread).
Running the WFC in its own thread, each client is receievd in different
threads.
Click to expand...

Define "main thread". Is this a Forms or WPF program?

I'm not that familiar with WCF, but it would make sense to me if WCF
automatically marshals i/o completions onto the message-pumping thread
(i.e. the "main thread") that created the original WCF object when
possible. The i/o operations themselves would still execute on a
different thread, but your client code only sees the result on the main
thread.

When the WCF object is created on a thread other than the main thread
(either because there's not one or because you've explicitly done so as
here), there's no SynchronizationContext available for marshaling the
completions over to the main thread, and so they just get executed on the
thread in which they actually occurred. In that situation, any
cross-thread issues that might exist, you'd have to explicitly address
rather than relying on WCF to do it.
[...]
Is this working by design ?
Click to expand...

That depends on whether my theory is correct or not. :) But, assuming it
is then yes, that would be by design.
Running the WFC host in its own thread, makes the code more responsive,
but
i'm not sure whether its ok to start the WCF listener in its own thread
or
not. Is it ??
Click to expand...

Assuming my theory is correct...

As long as you're comfortable dealing with any cross-thread issues that
might exist, I'm sure creating the WCF object in its own thread is fine.
And it makes sense that doing so would make the code more responsive (if
my theory is correct), because it means that the i/o completions don't
have to compete with your main thread's operations in order to execute,
and so can be handled in a more timely manner.

Pete
 
Hi Peter,

Thanks for your comments.

Its a Forms project.
Creating the service host in a sub-thread, return all requests in
sub-threads only. It is as expected - i just want to be sure.

On client requests, the service may have to collect some data before
returning, and i just don't want that to happen on the main thread (blocking
the main thread is a bad thing).

BR
Peter



Peter Duniho said:
[...]
The code starts a WCF listener and if i run this from the mainthread, all
re
Click to expand...
Click to expand...
 
Hi Peter,

The behavior is configured by UseSynchronizationContext attribute. This
attribute is true by default. So all server side call are synchronized to
main UI thread to be executed. If we do not want the server side functions
called under UI thread. We should set the attribute to false in the
Contract class.
http://blogs.msdn.com/mahjayar/archive/2006/11/07/winfx-usesynchronizationco
ntext-usage.aspx


Best regards,
Colbert Zhou
Microsoft Online Support Team
 
Hi Colbert,

So it is as Peter Duniho says - because the thread doesn't know about the
GUI synchronization context, it's simply return on its own thread ??

I think i have missed the UseSynchronizationContext attribute - its simplify
the code a lot - i will definitely use it from now on.

BR
Peter
 
Back
Top