Specific problems and General Solutions

 

Specific problems and General Solutions

Wu Yu

Taiyan Network Studio

 

The last time I posted an article "object-oriented misunderstanding and Technical Selection misunderstanding", I was questioned by my friends. I observed it with a cold eye and found that there are many people who have such doubts. It is estimated that I have not been clear enough to understand this misunderstanding.

 

I mistakenly thought yes. Actually, no, it is a misunderstanding.

I was surprised when I thought I would be deep! My friends mistakenly thought that I would oppose object-oriented programming, middleware, and third-party tools. How is this possible? Modern software engineering is so architecture-oriented and layered, and the project is so huge. If we don't do this, do we have to wait for everyone to do anything?

 

If you have caught a cold, generally (except for special cases). If you do not take the medicine, it will take 7 days. If you take the medicine, it will take 7 days. (I will also write an article about the treatment and software development, which will be discussed in detail later .) Therefore, we must first determine whether it is a general cold or a special case! Or a general cold turns into a special case, such as pneumonia. you still insist on not seeing a doctor. That is a bad thing!

When software development encounters technical problems, we should first consider whether it is a general problem or a special case! Not to distinguish between them. Just like seeing a doctor when you get sick, it seems reasonable. In fact, it is just to seek a kind of psychological comfort. In fact, in addition to wasting money, it is simply not helpful! Sometimes it is just as unreasonable as a toothache patient requires long-term hospitalization!

In-depth analysis is actually a classification problem. The classification of languages can lead to misunderstandings, for example,

It is close to saying that a whale is a fish;

It is said that the poison is a medicine, and it is also a bit of a side (it is a three-byte drug );

But it's too much to say that the snail bait is a cow!

One sentence on the internet is best about this type of problem:Can the Japanese also count as humans !?So everyone is quiet.

The same funny inferences are as follows:

It's right to see a doctor if you have a problem;

The patient is seriously ill. It is right to require long-term hospitalization, so the toothache is severe. It is also right to require long-term hospitalization!

Also:

It's right to see a doctor if you have a problem;

The physician is a doctor, so it is also right to contact the physician for toothache;

The veterinarian is also a doctor, so it is also right to find a veterinarian with a toothache.

It's just dumb!

 

I think the problem lies in our classification of one thing. I classified "CIN> OBJ" in "object-oriented misunderstanding and Technical Selection misunderstanding" into special cases under the current conditions and it is not recommended to use it (because the overhead of function calling is it is a serious problem in our program ); on the contrary, I classify the socket communication problems in our program into general problems, and do not need to use such powerful tools as Ace. In other words, the advantages of "CIN> OBJ" and ACE cannot be used in our programs at all, so I do not recommend using them.

In the discussion, I came to the conclusion that these things are not good, but most of them are incorrect! I have criticized the failure of using SAP in domestic ERP systems (in fact, there are many examples in the world). In fact, it is not sap bad, but we will not use it, or it is wrong to use it! It cannot be understood by everyone, but what is the consequence of pulling a horse? Not everyone can understand it.

 

"What is a broken horse? It's not easy to use. It's not as good as a donkey! Pig is better than it !"

 

Let's talk about a program I took over half a year ago. It will be more typical.

Our program needs a memory pool, where a thread sends the received data to the memory pool, and several other threads go to the memory pool to fetch the data for processing. Preliminary tests by original developers show that the processing speed is close to 10 m/s. It should be said that this can meet our requirements. Further tests after I took over found that it had a serious bottleneck problem. The general situation was: 10 Mb/s, 9 Mb/s, 10 K/s, and 9 K/s. That is to say, as long as you use it, its memory will be used up sooner or later, and the output will always be slower than the progress!

Me!

To ensure data security, it is common sense to use locks or mutex for multiple threads. As a result, the memory pool uses two locks for entry and exit, and multiple locks appear in the whole memory pool class. They guard the class like the Four Kings. The overall result is, this memory pool class cannot be used in any way.

 

Correction is still necessary!

I tried to re-design and develop the class in two days. I didn't use a lock or mutex, but it would perform data throughput like crazy, in our production line, the throughput speed is 60 m/s! Like a horse, it is incredibly fast and dizzy! However, it does have a fatal conclusion like a swift horse: it does not support multithreading well and does not support multiple threads at the same time!

The reason for this design is that I have adjusted the program architecture: It turns out that multiple threads request data from the memory pool in a "pull" way; I changed it to the memory pool to "push" data to multiple threads! In this way, my "qianqianma" can be used, and the performance of the program has been greatly improved. This bottleneck will no longer exist!

This is not a general solution, but a solution to a specific problem in a specific environment. A general solution should support both single thread and multi-thread.

 

The general solution is like the Java language. It can solve most common problems and also cross-platform. In other words, most general problems can be solved by general solutions. In other words, the problems that general solutions can solve are not a problem! But you should not use Java to develop rich interface problems, not it cannot, but not suitable! This is a problem that has never been designed to solve. It needs to be compensated by other external solutions.

Looking back, for the technical personnel, it is necessary to distinguish whether a problem is a general problem or a specific problem, whether it is a problem that the system itself can solve, or whether it is necessary to introduce an external solution, just like Mao Zedong's decision on where the Chinese revolution is going, we need to think more carefully!