[ASK]-关于多线程概念 [英] [ASK] - About Multithreading Concept

问题描述

大家好，我想问您关于多线程概念的问题.我有一个应用程序，每天使用唯一的成员代码处理大约2万条消息.但不幸的是，丢失了大约30个确认消息(输出).两个小时后，第二次测试，我刚发送了20条消息，幸运的是丢失的数据(30个确认消息)消失了.

我不明白这是什么问题，我认为如果主线程死亡，那么子线程也会死亡..在这个问题中，我作为主线程的应用程序也不会死亡.
您能否给我一个有关与此问题相关的多线程概念的解释? :doh::doh:

谢谢



在我的应用程序中，我有2个计时器，计时器 A 和计时器 B .
计时器 A 会定期检查信号，例如信号量概念，如果该信号是true或false.如果为true，则将处理诸如从数据库加载数据(约100条消息)之类的作业，直到完成(signal = false).

这些输出将首先插入到表中，然后Timer B 将执行类似于每1.5秒向客户端发送ack消息的工作.
主要问题是，输出的数量(总计ack)与输出表中的输入数量不相同，而我的应用程序(控制台)不再对其进行处理(请记住，由于这些原因，我的应用程序仍在运行)计时器).

Hi all, i wanna ask you about multithreading concept. I have an application that processing approximately twenty thousands messages /day with unique member code . But unfortunately about 30 ack-messages (output) lost. And two hours later, the second test, i have just sent 20 messages and fortunately the missing data (30 ack-messages) is out.

I''m not understand what is the problem, i think if mainthread die so child threads will be die too.. in this problem my application as mainthread is not die.
May you give me an explanation about multithreading concept related to this problem ??? :doh: :doh:

Thanks



In my application I have 2 timers, Timer A and Timer B.
Periodically Timer A will check an signal like semaphore concept I think, if that signal is true or false. If true, a job like loading data from database (about 100 messages) will be processed until finished (signal = false).

These output will be inserted to table first, and then Timer B will do a job like sending ack messages to client per 1.5 seconds.
The main problem is, number of output (total ack) is not same with incoming in the output table whereas my application (console) doesn''t processing it again (keep in mind that my application is still running, because of theses timers).

推荐答案

我无法用任何全面的方法来解释线程概念，因为:1)它需要写一整本书； 2)您没有提供任何代码来说明您的需求，因此很难通过适合您应用程序的线程方面来限制我的建议.您绝对没有线索来帮助您了解邮件丢失的情况.如果要添加一些代码和后续问题，请使用上面的改进问题".

因此，我仅向您提供一些避免常见错误的提示.

首先，动态情况下的一个常见错误:创建多个线程而不是重复使用它们.考虑到您有大量消息，还有一个或多个连接到您的应用程序的客户端(请记住，我对您的应用程序一无所知，因此，这只是一个示例).有些人过去为每个新连接创建新线程，并抱怨线程错误"，因为他们滥用了线程.在大多数情况下，您可以使用固定数量的线程，例如，一个用于接受新连接(侦听器)，一个或两个用于接收/发送所有消息.关于处理线程间通信的消息，您可能想看一下我的技巧/窍门"部分中的简短文章:

I cannot give you the explanation of the threading concept in any comprehensive method because: 1) it will require to write a whole book; 2) you did not provide any code to illustrate your needs, so it''s hard to limit my advice by the threading aspects which would fit your application. You gave absolutely no clue to help to understand your message losses. Please use "Improve question" above if you want to add some code and follow-up questions.

Therefore, I''ll just give you some hints used to avoid common fallacies.

First, one common mistake in dynamic situation: creating many thread instead of re-using them. Consider you have a mass of messages and also one or more clients who get connected to your application (remember, I know nothing about your application, so, this is just an example). Some people used to create new thread for every new connection and complained that "threading is wrong" because they misused it. In most cases, you can live with fixed number of threads, for example, one for accepting new connections (listener), one or two more for receiving/sending all of the messages. On processing messages for inter-thread communications, you may want to take a look at my short article from Tips/Tricks section: Simple Blocking Queue for Thread Communication and Inter-thread Invocation[^].

Also, this is not good is your main thread processes messages. Main thread should better be used for initializing of all mechanisms, threads, queues, etc. and for control over those.

Exception processing in threads: you will need to catch and process all exception on the very top of the stack of each thread (that''s it, on top of a main delegate used as a parameter in thread''s constructor). Don''t leave any threads (including main one) without such processing. At the same time, if you handle any exception anywhere in the middle (in other methods called in any threads), make sure you don''t block exception propagation up the stack. When you handle an exception, you should do processing you need and then throw a different exception (you might construct as a result of processing) or throw the same exception using throw without parameters.

These advices are too general, but it''s hard to give more untill you share more information on your application.

Based on additional details by OP, continued in next answer…

—SA

正在回答的后续问题(在之后添加到原始问题中)…

正确设计的某些细节应高度依赖于未知的我认为的信号之类的信号之类的信号"，以及您如何进行交易，换句话说，取决于交易属性.

但是，即使是现在，这显然也是一个糟糕的设计！
您遇到的主要问题是计时器.您正在做非常认真的事情，所以，如果您使用计时器，您怎么能期待任何可靠的结果呢?例如，您是否详细说明了一个动作过程，当计时器触发某些事务，而下一个计时器事件在上一个事件触发的处理由于某种原因而未完成时出现?这只是一件事...

不过，您不必考虑这一点.使用时间的整个想法是错误的.您应该使用两个永久线程，一个用于读取消息，一个用于发送.现在，轮询数据库(或其他任何东西)总是很糟糕，但是看起来像是给定的，所以使用Thread.Wait进行定期轮询也是如此，但只能在读取线程中进行.在线程之间建立消息队列，它还将服务器作为线程同步.我提供的阻止队列可以工作，但这取决于一些细节.彻底设计每个线程的退出条件.在每个线程的堆栈顶部添加异常处理.

忘记将计时器当作噩梦了. (另外，请注意约翰的笔记.)
而已.您的问题很可能会消失.

祝你好运，

—SA

Answering follow-up question (added to original question after )…

Some detail of the right design should highly depend on unknown "signal like semaphore concept I think" and on how you do transactions, in other words, on transactional properties.

However, even now it''s clear that this is a bad design!
Main problem you have is timers. You''re doing pretty serious thing, so how can you ever expect any reliable result if you''re using timers, I wonder? For example, did you elaborated a course of action, when a timers triggers some transactions, and next timer event comes when the processing triggered by the previous event did not finish, by whatever reason? And this is just one thing…

You don''t have to think about this though. The whole idea of using times is wrong. You should use two permanent threads, one for reading messages, one for sending. Now, polling database (or anything) is always bad, but it looks like it''s given, so do the periodic polling using Thread.Wait, but only in reading thread. Make a message queue between threads, it will also server as a thread synchronization. The blocking queue I offered could work, but it depends on some detail. Design exit conditions for each thread thoroughly. Add exception handling on top of each thread''s stack.

Forget using timers as a nightmare. (Also, pay attention on John''s note.)
That''s it. Most likely, your problem will be gone.

Good luck,

—SA

请勿使用计时器对象 (我一遍又一遍地重复再次).

在繁忙的系统上，不能保证发送计时器消息.改用实线程.实际上，您甚至可能要考虑使用线程池，以便在任何给定时间只能执行有限数量的线程.这在用于其他目的的系统上尤其重要，这样您就不必占用内存和/或CPU周期.

DO NOT USE TIMER OBJECTS (I say this over, and over, and over again).

On a busy system, the timer messages are NOT guaranteed to be sent. Use real threads instead. In fact, you might even want to consider using a thread pool so that only a limited number of threads can be executed at any given time. This will be especially important on a system used for other purposes so that you don''t hog the memory and/or CPU cycles.

这篇关于[ASK]-关于多线程概念的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！