- From: Walden Mathews <waldenm@optonline.net>
- Date: Mon, 24 Feb 2003 09:01:35 -0500
- To: www-ws-arch@w3.org
Glossarizers, There is a definite tension between what people seem to mean by "synchronous" and "asynchronous" in the scenarios document and the more formal and historicaly correct definitions of these terms. It's a little hard to bridge, but here's an attempt. At the root of the problem is the idea that two distinct parties to some operation have expectations of something occurring "at time T". In order for "at time T" to have coordinational meaning, both parties have to agree on what it means, which implies they can "see" the same clock. Same clock = "synchronous". Reasonable approximations also qualify, and I'm sure Arkin has a few algorithms standing by. Strictly, in order for there to be synchrony, there would also have to be a "discrete time" constraint. If time is not discrete, then it is impossible to name the time at which something occurs, let alone have two events occur at the same time. So, if you "send a message asynchronously", you are sending the message without regard for what time it is. Implied in "what time it is" is the state of the recipient, probably. For example, sending a request, regardless of whether it's at a time during which the server is active. Thus, saying "send asynchronously" is maybe too general a way to express the idea "send regardless of peer state". A more familiar use of the term "synchronous", in computing, does mean blocking a thread or process while waiting for a reply. While the blocking part may not be essential, the notion that a reply will arrive by some agreed time T is. Synchronous exchanges "time out", indicating that the allocated time expired before the reply arrived. Ironically, clients who "block indefinitely" or "block forever" are not strictly synchronous because "indefinite" and "forever" are neither discrete nor do they require any reference to a clock. "Timing out" may be the key to expressing what synchronous and asynchronous mean succintly and with minimal formalism. Would it be reasonable to say that synchronous activities may time out, while for asynchronous ones the term is not defined? One other thing to factor in, perhaps helpful. In berkeley socket speak, you can set "non-blocking" on a tcp socket, and/or you can set "asynchronous", a different property. Non-blocking means the thread doesn't wait even for the local stack to complete its processing; asynchronous means all connection events will be propagated as interrupts (signals in Unix). This is probably the extreme limit for interpretations of async. I hope this analysis is a little helpful in moving the definitions in the direction the group wants. BTW, I think the noun is "synchrony", not "synchronicity", which has metaphysical undertones. Walden
Received on Monday, 24 February 2003 09:01:44 UTC