Hi Joe,
Synchronization domain is referring to the synchronization context of a
ContextBoundObject. In the .NET Framework you can implement something known
as "Aspect-Oriented programming". In Aspect-Oriented programming an object
is created in it's own context based on aspects of the object such as
"requires synchronization" or "car is blue". Aspects are applied through a
ContextAttribute Attribute and custom ContextProperty objects, which are
given a chance, at runtime, to participate in the creation of a context for
an instance of a class on which the ContextAttribute adorns. The .NET
Framework ships with an aspect that handles automatic synchronization
between all instance methods of the object to which it is applied, which can
be any object deriving from ContextBoundObject.
System.Runtime.Remoting.Contexts.SynchronizationAt tribute applies an aspect
to a ContextBoundObject that has the semantics of, "I require a
synchronization domain for my context which ensures that all public instance
methods are executed in a synchronous manner". Adorning your
ContextBoundObject with this attribute ensures synchronicity between public
instance methods without requiring explicit synchronization code such as
locking or the use of wait handles.
ContextBoundObject uses the plumbing of the Remoting framework to handle
messages, and therefore works across application domain boundaries using
standard remoting channels and registration mechanisms just like
MarshalByRefObjects. As a matter of fact, ContextBoundObject derives from
MarshalByRefObject.
Having a context for an object also provides useful features for Remoting
not possible by any other means within the .NET Framework such as client
envoy sinks that are automatically distributed to remote clients and server
object sinks that are executed per instance as opposed to channel sinks
which apply to all remoted objects.
Aspect-Oriented programming with ContextBoundObjects:
http://msdn.microsoft.com/msdnmag/is...P/default.aspx
Injecting custom sinks:
http://msdn.microsoft.com/msdnmag/is...T/default.aspx
IMO the functionality provided by this little-known piece of the .NET
Framework pie could be very useful. The cost of using such a robust
mechanism may be performance but the benefits such as ease of use as opposed
to writing a custom solution may very well outweigh the negatives.
- Dave Sexton
"Joe" <Jo*@discussions.microsoft.comwrote in message
news:6E**********************************@microsof t.com...
Hello All:
I have been researching the WaitOne method and don't understand what the
second param is for. It is a boolean value that determines "whether to
exit
the synchronization domain before the wait." What does this mean?
How does the WaitOne (or, for that matter, WaitAny or WaitAll) differ from
a
synchronous call? To me they look effectively the same. Unless the
difference has to do with this "synchronization domain" thing.
Any help will be appreciated.
TIA,
--
Joe
