Click here to Skip to main content
14,877,782 members
Please Sign up or sign in to vote.
4.00/5 (2 votes)
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
Updated 8-Feb-11 4:07am
v3
Comments
   
OP comment moved to question, formatted.
--SA

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
   
v2
Comments
Nish Nishant 8-Feb-11 10:14am
   
Voted 5, quality answer.
   
Thank you Nishant.

More concrete answer is ready, based on OP additional information.
Moreover, I'm sure it should resolve the problem (after proper considering additional detail on transaction).

--SA
fjdiewornncalwe 8-Feb-11 12:03pm
   
+5. You answer's never lack depth. Well done.
   
Thank you for good words, Marcus.
--SA
   
Thank you for accepting my answer (actually my second answer is equally important, as well as John's).
Good luck and call back,
--SA
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
   
v3
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.
   
Comments
   
Thank you for strong reassurance - my 5.
--SA

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




CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900