WCF Master Class - Concurrency Management
We just finished up a Windows Communication Framework (WCF) Master Class taught by Juval Lowy, President of IDesign. Juval has been deemed a Software Legend by Micrsoft, and his knowledge of the WCF was impressive. I was interested in WCF before this class, and now I'm itching to start cranking on some WCF projects. I'll be sure to post here once I get something interesting underway.
For now, I've just posted some shorthand notes from our discussion of concurrency management. This obviously insn't a comprehensive list, but shows the main topics regarding concurrency we reviewed.
Service in-memory state
Client in-memory state during callbacks
Shared Resources
Static Variables
PerCall is by definition thread safe instance
Each call gets a dedicated instance
State store is NOT thread safe
PerSession requires concurrency managment
Singleton also must synchronize access
Multiple instances on multiple threads
ConcurrencyMode.Single:
Default value
Auto synch
Disallows concurrent calls
One caller at a time
Callers handled FIFO, placed in queue
Timeout defaults to 1 minute
Keep operations session-ful and singleton services short to avoid blocking for long
ConcurrencyMode.Mutliple:
Allows mutliple calls up to throttled concurrent calls value (default of 64)
Using .NET locks to synch access to its state
Lock just when required
Allow other clients calls in between
Does not queue up messages
This is a tad goofy, though, because sessionful and singleton don’t scale, so why scale throughput but not these?
[ServiceContract(SessionMode = SessionMode.Required)]
interface IMyContract
{
void MyMethod();
}
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple)]
class MyService : IMyContract
{
int[] m_Numbers;
List m_Names;
public void MyMethod()
{
lock(this)
{
...
}
/* Don't access members here */
lock(this)
{
...
}
}
}
BETTER TO LOCK ON (this) to hold entire object body, instead of locking particular members, to enforce safety even if other members are added later… add as static to avoid this, but if developer doesn't think to do this, then partial safety results, and deadlocks are possible as threads lock down resources in different orders.
ConcurrencyMode.Reentrant:
Refinement of .Single
No concurrent calls
Singles can deadlock when call chain references themselves
Reentrant avoids this by allowing reentrance into service instance, avoiding deadlock (Silently releases lock)
Created for duplex callbacks, as callback will reference calling client operation
Thread affinity - The assumption you always use the same thread
UI & TLS (local store) can assume thread affinity, but services cannot
Some cool form update examples in these examples (Application.OpenForms) updating of form controls, etc.