Hi Akash, It is not easy to answer your question shortly Synhcronious (synchronized) method guarantees thread safety inside the method. If any thread is innside the method and is in the Running state, no other thread can get into the method. The other thread gets in the "Seeking lock state". Asynchronious method (if doesn't have any synchronization blocks inside) doesn't guarantee thread-safety. That is: all shared objects (if they are not immutable) accessed inside the method by multiple threads can be corrupted or brought in inconsistent state. Best, Vlad [ October 29, 2003: Message edited by: Vlad Rabkin ] [ October 29, 2003: Message edited by: Vlad Rabkin ] [ October 29, 2003: Message edited by: Vlad Rabkin ]
Joined: Aug 21, 2003
Hi Vlad, Thanks for your response. May be i could not ask my question correctly. Many times, when reading technical document, i come across these terms Synchronous and Asynchrous. I think, they may not mean lock/unlock or share the object. Its something related to process or event. I was trying to read this document http://help.sap.com/saphelp_45b/helpdata/en/c5/e4ac1f453d11d189430000e829fbbd/content.htm through google search to get answer of my question. After reading this, i was trying to visulize this in Java, but i could not do. I was asking question to myself, does this mean if i put synchronized in a method, will it be a synchronous method, then all all other method are default asynchronous in Java, i got confused ? So, I posted this to get answers from Gurus. Execues me, if it is not be related to SCJD, but i feel, it is related to a business method design in general. Regards, Akash
Hi Akash, Are you trying to understand the SAP specific usage of these terms, or are you trying to understand it in general computer terms? The meaning of Synchronous and Asynchronous is translated loosely depending on usage. Syn is Greek for "together" and "chronous" is Greek for time (IIRC). The 'a' of asynchronous just negates the "synchronous". Gee - with Jim's Latin, we are getting quite scholarly here So in terms of a synchronized block, then all the parts within the synchronized block are treated as being a unit of work to be processed together in time. (no other thread can process the same units of work until the first is completed). Another common usage is in communications (and even here there are different meanings for high level and low level communications). But keeping it to high level, we talk about synchronous methods as being those methods whose order in time is known, and asynchronous methods as those methods who's processing order in time is not known. For example, in the SCJD project, one individual client believes that it's calls to the server are being handled synchronously. The client can send a find() request, and that will be processed before the client can send a book() request. But the internals of the lock() method are (usually) asynchronous. We do not know what order in time lock requests will be processed. Consider the following:
Client 'A' locks record 5
Client 'B' attempts to lock record 5
Client 'C' attempts to lock record 5
Client 'A' releases the lock on record 5
Now who gets the lock? Most people here are just calling notify() or notifyAll() in this case, with no special checking for which order the lock requests came in. So either client 'B' or client 'C' could get the lock. The processing was done asynchronously. (To make it synchronous you could add a list of waiting objects, and only send a notify() message to the first client who had called wait(). I have seen one person here do that to ensure that no client could starve waiting for the lock.) If you start working with JMS (Java Messaging Service) it becomes more important to you to determine whether you are going to work synchronously or asynchronously. Messages are placed on a queue by a remote client who does not know or care what your server is or even if it is currently online. So when you start to process messages, do you care about the order that the messages were placed on the queue, or not? In EJB terms, a Message Driven Bean treats messages as asynchronous - the message can be taken off the queue in any order. Does any of this help? Regards, Andrew
If talking about events which I think you are. Asynchronous messages are used to avoid multi-threading. They are effectively messages that do not block, i.e not function calls. Asynchronous message = message placed on buffers and processed at some time, with a response sent back via another message.
A synchronous event generally = function call. In UML --------------------------> Sychronous <--------------------------
Asynchronous messages are used to avoid multi-threading.
In Swing component, Event object is processed asynchronously by Single GUIEventThread. Is this a correct example for your above statement ?
They are effectively messages that do not block, i.e not function calls.
I am not able to understand that asynchronous message is "not a function call" while synchronous is a "function call" . Is it possible for you explain it more by some example.
Joined: Jul 03, 2003
Probably didn't explain it correctly. A sychronous message passes control to the called process, a good example is a function call that does something then returns when this is done. Asychronous messages genrally use message queues, so a message is placed on a process's queue, where it can be processed at some given time, when it is processed the process consuming the message may pass another message back to the calling process asyncronously with the result. The key is that this model does not block, the message can be processed whenever scheduled. The calling process does not give up the processor to process the message, as with synchronous messaging. So in this case a function call would put the message on a queue to be processed at a time convinient to the messaged process, the message would not be processed immediately. An example of a Asyc message Process A sends a message to process B ( to B's message buffer via a funtion call) Process A keeps processing ( So it hasn't blocked ), maybe sends messages to other process. Process A gives up control of the processor Process B gains control of the processor reads message queue, process's message sent by process A and sends a reply to process A's queue. Process B does something then gives up processor Process A gains processor and reads its message queue and gets response from its message to process B. So you can see this is a message driven system. Notice how a message driven system avoids blocking wiyhout the use of multiple threads. Syncronous Messaging Process A sends message to process B Control taken by process B until message processees and response sent to process A. ( Basically a function call) The Symbian OS makes heavy use of Asyncronous messaging to avoid the expense of context switching.
Tony [ October 30, 2003: Message edited by: Tony Collins ]
Joined: Aug 21, 2003
Hi Tony, Thanks for nice explanation. But, now I have more basic question to understand this, i hope you would not mind . 1. Does process(in your explanation) mean a thread or seperate process ( i mean running two instance of JVM) ? 2. Does context switch happen in process also, i mean when a processor switch from one process to other ? 3. How can i know which part of program is using what resource ? To my understanding, any Java program uses processor all statements except in the statement where it uses IO package clases to read/write from any stream, am i right ?