[ASK] - About Multithreading Concept

Question

4.00/5 (2 votes)

See more:

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

[EDIT]

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).

Posted 7-Feb-11 17:36pm

Teamsar Muliadi

Updated 8-Feb-11 4:07am

Sergey Alexandrovich Kryukov

v3

Add a Solution

Comments

Sergey Alexandrovich Kryukov 8-Feb-11 10:05am

OP comment moved to question, formatted.
--SA

3 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2011-02-07T18:10:00

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

Sergey Alexandrovich Kryukov · Accepted Answer · 2011-02-08T04:22:00

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

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

#realJSOP · Accepted Answer · 2011-02-08T04:33:00

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] - About Multithreading Concept

3 solutions

Solution 1

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

Solution 2

Solution 3

Add your solution here

Preview 0