Sorry, this article can't talk about what articles, just a little bit of experience in the C forum, the reason why it is extracted here is 2: One is the forum and the other, I am eager to hear here. The voice of criticism; the second is never published here the experience of publishing articles here, some curiosity :-)
Main topic: What is the thread? Author: ANRXHZH (Treasure Chest), etc.: Credit: 110 Forum: C / C problem points: 200 Repose: 28 Posted: 2002-8-6 20:41:20
The initial contact thread is to pass Win32 API CreateThread, feel very simple, thread is an execution clue, and there can be one or more clues in the process. Later, I came into contact with MFC CWINTHREAD, it is very convenient to use. Then, due to the relationship of the work, it is basically no MFC, turning to cross-platform C programming, so it is quite proud of CWINTHREAD.
Nowadays, this thread class has increased the coupling of the software. Due to the existence of such a thread class, I can't help but put a lot of business logic in it, this is almost the temptation that cannot be resistant. But in this way, once the scheduling strategy changes, it takes a lot of effort to peel off the business logic from the thread class.
Look at Boost :: Thread, very inspired, it completely separated the port of thread objects and threads. It is still not used to just start, but this design must have its truth. The thread is actually a scheduling clue, which is only possible to make the scheduling policies and business logic changes independently.
For example, in the network programming, the server often has such a design, the main thread monitor port, starting a thread for each customer, and may generate a class such as ClientThread, the advantage of this design is concise, but with the business The expansion may not be able to start enough customer threads, you must change the design, let a thread handle multiple customers at the same time, the pain is coming, you must extract the Client of the previous clientthread. If we enforce CLIENTTHREAD in the beginning, it is more clearly available in both ports of Client and Thread.
The above is a preliminary feeling, but I haven't thought about it. I hope everyone will discuss it.
Reply to: ANRXHZH (Treasure Chest) () Reputation: 110 2002-8-8 14:00:53 Score: 0
Class thread: private noncopyable {public: thread (); explicit thread (const function "; ~ threadfunc); ~ thread ();
Bool Operator == (const thread & other) const; bool operator! = (const thread & other) const;
Void Join ();
This is a Boost thread class. Seeing it for the first time, very happy, so simple, definitely reliable, you can do it for what you want. To know that the thread class I originally designed can be powerful, you can pause, restore, terminate, start, log, and even build a thread tree, send a notification information to the GUI, and now I am afraid. Now I want to come, the thread is a scheduling clue, the interface provided by boost :: thread is almost the same, the more harmful interfaces. Squiration is transmitted, Boost :: Thread has several different design: 1. Threadfunc and thread are separated, not a virtual method. 2. The prototype of ThreadFunc is Void F (), not Void F (void *). 3. Threadfunc can be a function object, and thread will save a copy of the object inside, this copy of the life period is not less than the conviction period of the thread.
Why do you want to design it, I hope everyone will discuss it. Let me talk about my opinion first: 1. The post I asked has answered, which is to isolate the scheduling policy and business logic. 2.void F (void *) is unreliable, Void F (Void) can enforce you to improve the design of the program. 3. Hold the reservation attitude. I tested it. If Thread Object is destroyed during the thread survival, the copy will not be released. Of course, if it is called Join (), there is no such problem, but this is a limit. More importantly, the function object must provide a copy constructor, which is even greater, and some classes are unable to provide copy constructor.
