I realize I am way late for this party, but I would like to make a specific theoretical point about synchronous vs. asynchronous communication. It turns out that, given some components or modules or threads or what-have-you communicating via sending messages to one another, synchronous communication is actually more general than asynchronous in the following technical sense. Once can always use synchronous communication to implement asynchronous communication by throwing another module in the middle to act as a mailbox. On the other hand, given only asynchronous communication, it is impossible to implement synchronous communication. Thus, I dearly hope, unlike nazgulnarsil3, that I never see the day where we forget that synchronous communication is strictly more powerful than asynchronous. Moreover, this is not analogous to the wood/nonwood situation where they are entirely different—in fact, in the synchronous/asynchronous situation, one entirely subsumes the other.
This says nothing about that fact that it requires more computing power to encode asynchrony as synchrony (although only linearly more in the number of communication channels). Moreover, it certainly says nothing about central vs. distributed models, which is an orthogonal issue to synchronous vs. asynchronous communication.
Yes, of course asynchronous systems can be encoded in synchronous. But the opposite is true as well. Asynchronous is not “no sychronization”, but “explicit, as needed, synchronization”, and it can encode fully synchronous architectures at the loss of some efficiency (i.e. gating everything to a central clock unit, that lets everything step forward one unit at a time).
Disclaimer: I’ve worked on designs for asynchronous hardware.
Point taken, but I think it is a matter of definition. Let me rephrase. It is impossible to implement synchronous communication without some synchronization mechanism, and thus entirely asynchronous systems cannot implement synchronous communication.
This statement may be entirely obvious, but I think that is only because thought has been put into properly stating the issue. More to the point, what I am actually trying to say is that the original post seems to imply that settling on synchronous communication is somehow more limiting than settling on asynchronous communication, and that this is false.
You can FAKE asynchrony with a synchronous system (using threading and such), but you can’t really be asynchronous. If the hardware only processes one step at a time, you can’t make it process two steps at once!
I realize I am way late for this party, but I would like to make a specific theoretical point about synchronous vs. asynchronous communication. It turns out that, given some components or modules or threads or what-have-you communicating via sending messages to one another, synchronous communication is actually more general than asynchronous in the following technical sense. Once can always use synchronous communication to implement asynchronous communication by throwing another module in the middle to act as a mailbox. On the other hand, given only asynchronous communication, it is impossible to implement synchronous communication. Thus, I dearly hope, unlike nazgulnarsil3, that I never see the day where we forget that synchronous communication is strictly more powerful than asynchronous. Moreover, this is not analogous to the wood/nonwood situation where they are entirely different—in fact, in the synchronous/asynchronous situation, one entirely subsumes the other.
This says nothing about that fact that it requires more computing power to encode asynchrony as synchrony (although only linearly more in the number of communication channels). Moreover, it certainly says nothing about central vs. distributed models, which is an orthogonal issue to synchronous vs. asynchronous communication.
Yes, of course asynchronous systems can be encoded in synchronous. But the opposite is true as well. Asynchronous is not “no sychronization”, but “explicit, as needed, synchronization”, and it can encode fully synchronous architectures at the loss of some efficiency (i.e. gating everything to a central clock unit, that lets everything step forward one unit at a time).
Disclaimer: I’ve worked on designs for asynchronous hardware.
Point taken, but I think it is a matter of definition. Let me rephrase. It is impossible to implement synchronous communication without some synchronization mechanism, and thus entirely asynchronous systems cannot implement synchronous communication.
This statement may be entirely obvious, but I think that is only because thought has been put into properly stating the issue. More to the point, what I am actually trying to say is that the original post seems to imply that settling on synchronous communication is somehow more limiting than settling on asynchronous communication, and that this is false.
You can FAKE asynchrony with a synchronous system (using threading and such), but you can’t really be asynchronous. If the hardware only processes one step at a time, you can’t make it process two steps at once!
The parent seems to have been discussing (a)synchronous messaging, whereas you seem to be discussing (a)synchronous computation.