Definition of Synchrony (was Re: Snapshot of Web Services Glossary)

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