Hi Joe,
Synchronization domain is referring to the synchronization context of a
ContextBoundObj ect. 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
ContextAttribut e 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 ContextAttribut e 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 ContextBoundObj ect.
System.Runtime. Remoting.Contex ts.Synchronizat ionAttribute applies an aspect
to a ContextBoundObj ect 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
ContextBoundObj ect with this attribute ensures synchronicity between public
instance methods without requiring explicit synchronization code such as
locking or the use of wait handles.
ContextBoundObj ect 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
MarshalByRefObj ects. As a matter of fact, ContextBoundObj ect derives from
MarshalByRefObj ect.
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 ContextBoundObj ects:
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*@discussion s.microsoft.com wrote in message
news:6E******** *************** ***********@mic rosoft.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 "synchronizatio n domain" thing.
Any help will be appreciated.
TIA,
--
Joe
