Take the 2-minute tour ×
English Language & Usage Stack Exchange is a question and answer site for linguists, etymologists, and serious English language enthusiasts. It's 100% free, no registration required.

In JavaScript, why does synchronous and asynchronous appear to be the opposite to their definition?

Synchronous (in JavaScript this refers to running in sequence):

  • occurring at the same time; coinciding in time; contemporaneous; simultaneous.
  • going on at the same rate and exactly together; recurring together.

Asynchronous (in JavaScript this refers to something like AJAX):

  • not occurring at the same time.
  • (of a computer or other electrical machine) having each operation started only after the preceding operation is completed.
share|improve this question

migrated from stackoverflow.com Jan 29 '13 at 18:15

This question came from our site for professional and enthusiast programmers.

6 Answers 6

  • Synchronous means happening in sequence (as opposed to running in parallel, in which two things might be running at once)

  • Synchronized means happening at the same time.

share|improve this answer
1  
I think he already knows that... He stated as much in his question. –  Robert Harvey Jan 29 '13 at 18:14
1  
Synchronous means happening at the same time everywhere but in CS –  mako-taco Jan 29 '13 at 18:14
1  
@RobertHarvey: Then I have no idea what he's asking. –  SLaks Jan 29 '13 at 18:14

It has to do with the way the communication from client to server happens. synchronous means "going on at the same time": the client and server are tied up with each other, "synchronously" communicating, but blocking the next bit of code from running.

on the other hand asynchronous communication can happen in the background where the client sets off the communication routine and it just "goes".

the words are used in the same way to describe human communication. telephone and face to face conversation are synchronous methods while asynchronous methods include email, sms, or physical letters.

share|improve this answer
    
Actually, this distinction applies independently to either side of the connection. Each side has no idea whether the other side is using a synchronous socket API or not. –  SLaks Jan 29 '13 at 18:25
    
good point. oddly enough, as a programmer i'm more clear on the distinction between the two types when applied in real life. –  hhamilton Jan 29 '13 at 19:51

You have the generic definitions of synchronous/synchronized/a synchronous ad not synchronized just fine. The usage in programming systems is not opposite, it is extended from the generic.

Two processes synchronized means they work on the same clock; even if they don't occur at exactly the same time (they very well may), they communicate in an expected manner according to time stamp.

Two asynchronous processes may communicate but they wait for each other, there's no expectation that one must take exactly a given amount of time.

share|improve this answer

Synchronous means 'happening at the same time'.

Synchronized means 'made to happen at the same time'; the -ize derivational suffix is a causative.

share|improve this answer

To start with the English definitions again:

When we say that two or more things are synchronous we may just mean that they are happening at the same time, or we may more specifically mean that they are keeping pace with each other.

Asynchronous refers to the lack of whatever quality we're using synchronous to talk about.

Now, there are two important cases in computer science where this distinction comes up that are irrelevant for Javascript, but show how the jargon uses are really just a specialisation of the above rather than (as some jargon is) a new sense.

One case is in communications. With a synchronous communication, we need two devices to keep in step with each other. This may refer to the timing of bits sent along a wire or other medium, all the way up to the higher communication protocols built on top of that.

With an asynchronous communication, we do not need two devices to keep in step, and one can race ahead or fall behind without breaking the communication. Again, this may refer to the low-level transmission of bits, all the way up to higher communication protocols (some like TCP/IP may even allow bits of the message to arrive out of order and be put back into order again later).

While there's generally more work involved in making any given layer work asynchronously, there's generally advantages as it's more reliable (won't break due to timing issues), more flexible (being able to build a system on top of media that operate at variable speeds rather than lock into the lowest speed you can guarantee), and hence it can also even make things easier at the layer above.

As we can see, this relates directly to the normal English-language sense of synchronous where two or more things are keeping pace with each other.

Now, another case is with multithreaded programming (much of what I'll say now also goes for multiprocess systems with communication between them, and some other cases, but I'll just stay with multithreading for the description). When we have a multithreaded program, different parts of it can run simultaneously (or concurrently). Sometimes, it may be necessary to coordinate the work of these threads, for example to collate final results, or to make use of a shared resource that can only tolerate access from one thread at a time.

When we need to synchronise different threads like this, we are using synchronisation. However, the less we can have different threads depend on each other like this, the more efficient things would be overall, because one suffering a delay will not hurt the others.

For that reason, we have a variety of techniques for dealing with I/O, accessing APIs, or delegating work to other machines which are designed to not require this sort of synchronisation between different threads, but will handle the fact that we then can't depend upon the success or failure happening to any given time-frame. Since these simultaneous processes need not be synchronised in the sense of being kept in time with each other, we call each of these techniques asynchronous.

Again, we can look back at the general English definitions and see why they are called what they are called, at least in comparison to each other.

Now, Javascript does not have multiple threads*, and for the uses it is used for that is just as well, it would be far more trouble that it's worth. This means that we don't have to think about the concerns just mentioned, but also means that if we do something that takes a long time (like accessing a stream from the web), the single thread will be stuck waiting and doing nothing else.

So we have another option: We start a network operation, and then leave it to run and our script continues until it is finished. When the network operation concludes, this triggers an event that lets our single thread act on the results.

While there is only one thing happening at a time in the Javascript (though there are two or more operations happening in the browser overall) the technique is a copy of some of the asynchronous techniques used in multithreaded systems to avoid the need for synchronisation between threads.

So there we have an answer that is perhaps too programming-related to suit EL&U and too English-language focused to suit migrating back to Stackoverflow, but an answer all the same.

*Though different scripts can run on different threads in e.g. different server requests for server-side script, or different tabs on a browser for client-side web scripts.

share|improve this answer

From section 3 of the OED entry for asynchronous, adj.

a. Of a computer or part of one: not operating in accordance with clock signals; (of operations) beginning when the previous operation finishes, rather than occurring at regular intervals of time.

b. Designating data transmission in which packets of data are sent at irregular intervals, with the start and end of each packet being marked by specific signals; involving such transmission.


I don't know Javascript, but in my experience, asynchronous routines are those which are initiated by interrupts external to the (historically, single-threaded) control logic of the currently-executing program. That sense seems to derive from 3b above, if we allow that receive a data transmission can be stretched to mean honour a transmitted request to start executing some particular code.

I suggest that therefore the Javascript sense of synchronous is probably simply the opposite of that usage (i.e. - routines executed by consecutively stepping through the main process control logic).

It's a bit quirky that OED's definition 3a seems to match Javascript's synchronous better than asynchronous. I guess it's just that OED defines things relative to an external "real-world clock", but the Javascript definitions are relative to the internal process of code execution.


OP's headline “synchronized swimmers” are a completely different kettle of fish, directly reflecting a derivation from OED's synchronism, n.

concurrence of two or more events in time (the fish all move in the same way at the same time).

share|improve this answer
    
You're close on interrupts, it's an event-based single-threaded model, though they aren't asynchronous in that sense, where hardware interrupts are asynchrous and can interrupt running code, but closer to software interrupts which—in the context of interrupts—are synchronous. You're also correct on the sense of synchronous, the APIs the script uses (strictly, not part of Javascript itself) used the term asynchronous because they used event-based techniques that are asynchronous in a context where there are also synchronous concurrent approaches, and JS coders back-formed synchronous. –  Jon Hanna Jan 30 '13 at 1:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.