Shulou(Shulou.com)06/03 Report--

If you see my article for the second time, welcome to scan the code at the end of the article to subscribe to my personal official account (cross-border architect).

It will be delivered to the official account at 8 o'clock every Friday morning. Of course, I will add a meal from time to time.

In the previous article, Brother Z talked to you about the meaning of asynchronism and how to use it. Those who miss this article can take a look at it before coming back (distributed system concerns-- deep and simple "async").

In fact, I know that many friends are easy to confuse "asynchronous" and "non-blocking". The mental impression may be like this: async = non-blocking, synchronization = blocking?

In fact, this is not the case, Brother Z. I want to help you figure out this problem this time.

Synchronization and blocking / non-blocking

In the code you usually write, most of the "synchronous" calls are essentially "blocking". But synchronous calls can also have a "non-blocking" effect.

Let's take the example of queuing up to buy milk tea mentioned in the previous article to see why it is called "synchronization" + "blocking".

The example of "synchronization" in the article says that you wait in line to buy milk tea, order to continue to "occupy the pit", do not let the people behind order, wait for the clerk inside to make milk tea, you take away the back order. This is actually "synchronization" + "blocking". Where is "blocking" reflected?

Because at this time you have been "occupying the pit", for fear that the person behind you will order first, causing the shop assistant to do it for him first. So, at this time, you just stare inside, and this is "blocking", because there's nothing you can do but stare.

How can "synchronization" not be blocked?

That is, although you are still waiting in line to "occupy the pit", people are not idle, bowing their heads and playing with their mobile phones, asking from time to time, "is my milk tea ready?" is my milk tea ready? " . This is "non-blocking", because there will be an interval between your two inquiries, and you can do other things at this time. In essence, it achieves the effect of "non-blocking" by breaking the original "big synchronization" into multiple "small synchronization".

In the image above, the empty space between several blocks can be used to do other things, so it is "non-blocking".

Asynchronous and blocking / non-blocking

The "asynchronous" example in the previous article is a "non-blocking" example, and let's see why.

After the milk tea shop divides the order area and the pick-up area, the prepared drinks can only be taken from the pick-up area, which means that the person who receives your order is not the person actually making milk tea. At this time, you will get a pick-up number, and then honestly go to the pick-up area to wait, rather than "occupy the xx is not xx".

If you are in a hurry to get milk tea, keep asking, "is my milk tea ready?" Then this is still the "synchronous" + "non-blocking" mode. Because this process does not produce a "callback", you are constantly initiating "requests".

But if you are not in a hurry, just start a round of chicken eating on the side, wait for the number to be called inside, and then get it when it comes to your number. This is "asynchronous" + "non-blocking". Because this thing is triggered by the other party (the clerk inside), this is the "callback", which is the response to your previous "order" request. Complete a complete interaction one at a time.

At this point, you may say, isn't async still naturally "non-blocking"? No 、 No 、 No .

It's up to you to decide whether to block or not. You can block it. For example, when you wait for a "callback" and find that you don't have your cell phone with you, you can't play chicken, so you can only wait there foolishly and do nothing. In this way, the process is still "asynchronous", but it is "blocking" for you.

Synchronous / asynchronous at work & blocking / non-blocking

"synchronization" + "blocking". This is the most common, most of the usual code is like this, so I won't say much about it.

In fact, if you think about it carefully, you will find that many well-known frameworks are "synchronous" + "non-blocking". Why? Because you can continue to write code like "synchronous", but you can enjoy better performance similar to "asynchronous", why not?

For example, the io reuse model poll/select/epoll in the famous linux is essentially "synchronous" + "non-blocking". There is also a well-known network communication framework Netty.

We can also use this pattern when designing external api to reduce the impact of some time-consuming interface calls. This teacher Ruan Yifeng has written very clearly, so I will post a link directly: http://www.ruanyifeng.com/blog/2018/12/async-api-design.html.

The reason why people have the illusion that "asynchronism" = "non-blocking" is actually not unreasonable. Why? Because I searched through my mind, I really didn't expect any well-known framework / design to be implemented using "async" + "blocking". If any of you have anything to add, you can leave a message in the comments area.

There are more "asynchronous" + "non-blocking". Any frame that you see the callback keyword is.

Summary

All right, let's sum it up.

This time, Brother Z first talked about what was going on through the four combinations formed between synchronous / asynchronous and blocking / non-blocking.

Then I talked to you about where to see them at work and which mode would be appropriate in some typical scenarios.

I hope it will enlighten you.

Finally, I'll give you the best way to remember these four concepts.

Synchronous blocking: you do it. I'll watch you do it.

Synchronous non-blocking: you do it. I'll check it out every 5 minutes.

Asynchronous blocking: you do it. Tell me when it's ready. I'll wait.

Asynchronous non-blocking: you do it, okay, tell me, I'm going to do something else first.

If you still can't remember, remember that synchronous / asynchronous means "procedure" and blocking / non-blocking represents "state" in the process. As for where this sentence comes from, just come back and read this article.

Related articles:

The concern of distributed system-- "Asynchronous"

The focus of distributed system-- 360 °Omni-directional interpretation of "Cache"

Author: Zachary

Source: https://www.cnblogs.com/Zachary-Fan/p/blocknonblock.html

If you like this article, you can click "recommendation" in the lower left corner.

This will give me some feedback. :)

Thank you for your help.

▶ about the author: Zhang Fan (Zachary, personal WeChat account: Zachary-ZF). Persist in polishing each article with high quality and originality. Welcome to scan the QR code below.

Publish the original content regularly: architecture design, distributed system, product, operation, some thinking.

If you are a junior programmer, you want to promote but don't know how to do it. Or as a programmer for many years, I fell into some bottlenecks and wanted to broaden my horizons. Welcome to follow my official account "Cross-border architect", reply to "Technology" and send you a mind map that I have collected and sorted out for a long time.

If you are an operator, there is nothing you can do in the face of a changing market. Or you may want to understand the mainstream operation strategy in order to enrich your "warehouse". Welcome to follow my official account "Cross-border architect", reply to "Operation" and send you a mind map that I have collected and sorted out for a long time.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.