Observer Pattern - Push vs Pull Model

The Subject and the Observers can interact using a Push Model or a Pull Model

Push Model: The observer is notified that a change has occurred and must find out itself what changes have occurred.

In this model, the Subject pushes the state changes to the Observers. Push model can be used when all the Observers are interested in common state changes. Observers have no choice other than receiving the pushed data. Push model cannot be used with large amount of data, as an Observer may not be interested in all the data that is being pushed. Also, the Subject must know something about the Observer to which it is pushing the data. Therefore, the Observers have to comply with a standard interface required by the Subject and the Subject’s re-usability is limited to these Observers.

Pull Model: The subject sends observers detailed information about the change that has occurred (in the simplest case, the entire new state itself).Pull model is simple, but leads to further requests from the observer to the subject.

In this model, the Subject notifies the state change to the Observers and the Observers pull only the required data from the Subject. Pull model is more flexible and the Observers can pull only the required data. But, more than one method call is required to implement the pull model. The first method call is for change notification from the Subject to all its Observers and an interested Observer must call at least one more method to pull the data.

In a very dynamic environment, the state of the Subject can change between these two calls, that is before the Observer pulls the data. Therefore, the Subject and the Observers may not be in sync. Above all, the Observers call specific methods to pull the required data and it is up to them to figure out what is changed without getting much help from the Subject.

Push vs Pull
The push/pull note is more about how information about what happened is transferred once the notification need arises. push/pull model differ in different sorts of coupling associated with each approach.

Push requires that the Subject know what information the various Observers may need. So to avoid Subject knowing about individual Observers, one needs to provide a superset of information that includes everything observer might need.

Pull eliminates that coupling on Subject's part but it forces the Observer to ask explicitly for the Subject state data that it needs. Presumably the Observer will never need anything that isn't a public responsibility of Subject, so the pull model tends to be fairly benign and is commonly used when the relevant state data is nontrivial. The downside is that one needs to deal with the synchronization problem.

From Event Channel perspective:

Push Model - Suppliers generate events and actively pass them to an event channel. In this model, consumers wait for events to arrive from the channel.

Pull Model - A consumer actively requests events from the channel. The supplier waits for a pull request to arrive from the channel. When a pull request arrives, event data is generated and returned to the channel.

 Advantages of Pull Agents - They work when the client application is hosted behind a firewall – this is because all of its traffic is outbound. They are simpler to write than Push agents.

 Advantages of Push Agents - They are much more efficient than pull agents: messages are only sent when data needs to be sent. They are faster in that a message is delivered as soon as it is available to be delivered – it does not need to wait until the next time the receiver does a poll for the message to be delivered. They are potentially more secure (if set up correctly).

InvokeRequired : Accessing Windows Controls thread safe in C#

InvokeRequired Property:
Gets a value indicating whether the caller must call an invoke method when making method calls to the control because the caller is on a different thread than the one the control was created on.

Access to Windows Forms controls is not inherently thread safe. If you have two or more threads manipulating the state of a control, it is possible to force the control into an inconsistent state. Other thread-related bugs are possible as well, including race conditions and deadlocks.

It is important to ensure that access to your controls is done in a thread-safe way.The .NET Framework helps you detect when you are accessing your controls in a manner that is not thread safe. When you are running your application in the debugger, and a thread other than the one which created a control attempts to call that control, the debugger raises an InvalidOperationExceptionwith the message, "Control control name accessed from a thread other than the thread it was created on.

Ref:
http://msdn.microsoft.com/en-us/library/system.windows.forms.control.invokerequired.aspx

http://msdn.microsoft.com/en-us/library/ms171728(VS.80).aspx

http://weblogs.asp.net/justin_rogers/pages/126345.aspx

Asynchronous Calls using Delegates in C#

Asynchronous Delegate provide the ability to call a synchronous method in an asynchronous manner. When you call a delegate synchronously, the Invoke method calls the target method directly on the current thread. If the compiler supports asynchronous delegates, then it will generate the Invoke method and the BeginInvoke and EndInvoke methods.

If the BeginInvoke method is called, the common language runtime will queue the request and return immediately to the caller. The target method will be called on a thread from the thread pool. The original thread, which submitted the request, is free to continue executing in parallel to the target method, which is running on a thread pool thread. If a callback has been specified on the BeginInvoke, it will be called when the target method returns. In the callback, the EndInvoke method is used to obtain the return value and the in/out parameters. If the callback was not specified on the BeginInvoke, then EndInvoke can be used on the original thread that submitted a request.

The .NET Framework allows you to call any method asynchronously. Define a delegate with the same signature as the method you want to call; the common language runtime automatically defines BeginInvoke and EndInvoke methods for this delegate, with the appropriate signatures.

The BeginInvoke method is used to initiate the asynchronous call. It has the same parameters as the method you want to execute asynchronously, plus two additional parameters that will be described later. BeginInvoke returns immediately and does not wait for the asynchronous call to complete. BeginInvoke returns an IasyncResult, which can be used to monitor the progress of the call.

The code in this topic demonstrates four common ways to use BeginInvoke and EndInvoke to make asynchronous calls. After calling BeginInvoke you can:

1. Do some work and then call EndInvoke to block until the call completes.

2. Obtain a WaitHandle using IAsyncResult. AsyncWaitHandle, use its WaitOne method to block execution until the WaitHandle is signaled, and then call EndInvoke.

3. Poll the IAsyncResult returned by BeginInvoke to determine when the asynchronous call has completed, and then call EndInvoke.

4. Pass a delegate for a callback method to BeginInvoke. The method is executed on a ThreadPool thread when the asynchronous call completes, and can call EndInvoke.

Always call EndInvoke after your asynchronous call completes.

Reference:

Asynchronous Programming Overview -
http://msdn.microsoft.com/en-us/library/2e08f6yc(VS.71).aspx

Asynchronous Delegates - http://msdn.microsoft.com/en-us/library/22t547yb(VS.71).aspx

.NET Delegates: Making Asynchronous Method Calls in the .NET Environment - http://msdn.microsoft.com/en-us/magazine/cc301332.aspx

How to call a Visual C# method asynchronously - http://support.microsoft.com/kb/315582

Asynchronous Method Invocation By mikeperetz - http://www.codeproject.com/KB/cs/AsyncMethodInvocation.aspx

[UnmanagedFunctionPointer(CallingConvention.Cdecl)]

In .NET when calling Unmanaged Code from Manged Code using Delegates,Callback functions are implemented in .NET using delegates, and all delegates use the StdCall calling convention.

Use " [UnmanagedFunctionPointer(CallingConvention.Cdecl)]" attribute while declaring the delegate if your unmanaged Win32 API is declared with Cdecl calling convention.

Ref:

http://www.informit.com/guides/content.aspx?g=dotnet&seqNum=473

http://social.msdn.microsoft.com/Forums/en-US/clr/thread/8f62e785-691e-4fe8-87fb-1f60657c80aa