Callback--closure--synchronous--asynchronous--blocking--non-blocking

Callback--A pointer to a method is passed to the event source, and the event source calls this method in turn after the event has occurred. This method is called a callback function.

In Java, a callback function is typically defined by an abstract class or interface, such as:

Interfacecallbacki{voidcallback (Object obj);}classAImplementscallbacki{PrivateObject obj;  Public voidcallback (Object obj) { This. obj =obj; }     Public voidGetInfo (b b) {b.event ( This) ; }}classb{ Public BooleanSomethinghappend () {//dosomething ....        return true ; }     Public voidevent (Callbacki callback) {if(Somethinghappend ()) Callback.callback (Someinfo); }}

A need to get some information from B, and then call the even method of B, and pass itself as a parameter, b after the event occurs and processing ends (Somethinghappend return), call A's callback method (callback function) to pass the information will be a.

The observer pattern in the Java API is an example of a callback mechanism:

     Public void notifyobservers (Object Arg) {            if (!  Changed)                return;             = Obs.toarray ();            Clearchanged ();        }          for (int i = arrlocal.length-1; i>=0; i--)            ((Observer) arrlocal[i]). Update (this, arg);    }

This code is the Notifyobservers method in the observable class, which, after the event occurs, callbacks the Observer Update method to inform the observer.

The Hollywood principle in design mode, I feel also is a performance of the callback mechanism, the lower component relies on the high-level component, the high-level component calls the low-layer component interface method to adjust the lower component.

The Hollywood principle is: Don't call us, I'll call you if you need anything.

Dependency inversion: Rely on abstract programming, do not rely on the implementation of concrete, low-level concrete components should rely on high-layer abstract components; I feel that dependency inversion is an achievement of Hollywood principles.

Ajax is also an example of a callback mechanism,

Xmlhttp.open ("GET", "ajax_test.asp",true); Xmlhttp.onreadystatechange=function()  {  if (xmlhttp.readystate==4 && xmlhttp.status==200)    {    document.getElementById ("mydiv"). innerhtml=xmlhttp.responsetext;    }  } Xmlhttp.open ("GET", "Test1.txt",true); Xmlhttp.send ();

This function is a callback, which is called when the server returns a result to the browser.

When I was looking at the callback mechanism, I suddenly thought that Ajax was an asynchronous call, and that I was writing a synchronous call (not related to the callback mechanism), so I wanted to summarize last week's understanding of synchronous, asynchronous, blocking, non-blocking

The concept of synchronous and asynchronous is that the mechanism of message passing is different, and the synchronous call does not return until the result is returned, but actively waits for the return result; The asynchronous call returns immediately before the result is obtained, that is, the asynchronous call does not immediately return the result, but instead waits for the caller to give the caller a signal to process the returned result when the signal appears.

Blocking and non-blocking is the way the program waits for the result to be called, the blocking method suspends its own process or thread until the result is received, waits for the data to end during the receipt of the resulting data, and the non-blocking immediately returns a result that does not cause the process or thread to enter a waiting state.

5 Types of I/O models for Linux

Blocking I/O: Recefrom before returning (no result), the process hangs and enters the waiting state? , and when IO is in progress, wait for IO to end, which belongs to synchronous IO

Non-blocking I/O: Recefrom returns a flag bit immediately when there is no IO result, and waits for IO to end at Io, which is a synchronous IO

IO multiplexing: Select returns a flag bit immediately when IO is not ready, checks for data readiness with the polling flag, and waits for IO to end at Io, which is a synchronous IO

Task-driven: Four nation when IO is not ready, it returns a flag bit (non-blocking) immediately, and in the IO process, waits for the IO to end, belongs to the synchronous IO

Asynchronous IO: When the IO is not ready, a flag bit (non-blocking) is returned immediately; When IO is ready, the OS kernel completes the IO and then notifies the asynchronous IO process to handle the data rather than waiting for IO during IO, so it belongs to the asynchronous IO

For the time being, it's not quite right ... When I have time to think about these things.

Callback mechanism//http://blog.sina.com.cn/s/blog_77c632410101cjty.htm

Public voidnotifyobservers(Object Arg) {
    /*
* A temporary array buffer, used as a snapshot of the state of
* Current observers.
     */
Object[] Arrlocal;

synchronized( This) {
        / * We don ' t want the Observer doing callbacks into
* Arbitrary code while holding its own Monitor.
* The code where we extract each Observable from
* The Vector and store the state of the Observer
* needs synchronization, but notifying observers
* does not (should not). The worst result of any
* Potential race-condition:
* 1) a newly-added Observer would miss a
* Notification in progress
* 2) A recently unregistered Observer would be
* Wrongly notified when it doesn ' t care
         */
if(!changed)
            return;
Arrlocal =Obs. ToArray ();
Clearchanged ();
}

     for(inti = arrlocal.length-1; i>=0; i--)
((Observer) arrlocal[i]). Update (This ,Arg;
}

Callback--closure--synchronous--asynchronous--blocking--non-blocking