Semaphore's with Threads.

Question

3.50/5 (2 votes)

See more:

Hello All,

I am having a memory leak in my application. When I use semaphore, the threads that are stuck waiting for other threads to arrive are giving me memory leak.

How do I release threads that are stuck and how do I know how many are in there?

Any help will be appreciated.

Thanks In advance.

C++

void CTestManualThreadDlg::OnStartStop()
{
	m_EventEnd.ResetEvent();
	m_pMainThread = AfxBeginThread(MainThread, this,THREAD_PRIORITY_NORMAL,0,CREATE_SUSPENDED);
	m_pMainThread->m_bAutoDelete = FALSE;
	m_pMainThread->ResumeThread();
}
UINT CTestManualThreadDlg::MainThread(LPVOID p)
{

	CTestManualThreadDlg * Me = (CTestManualThreadDlg *)p;
	Me->MainThread();
	return 0;
}
void CTestManualThreadDlg::MainThread()
{
	static int m_mainvar = 0;
	CString Test;
	while(WAIT_TIMEOUT == ::WaitForSingleObject(m_EventEnd.m_hObject, 0))
	{
		m_mainvar++;
		Test.Format("%d", m_mainvar);
		m_MainThread.SetWindowText(Test);
		for (int x= 0; x<10; x++)
		{
			ChildThreadData *pData = new ChildThreadData;
			pData->pDlg = this;
			pData->ThreadNumber = x;
////THIS ARE SET FOR AUTODELETE....
			m_pChildrenThread[x] = AfxBeginThread(ChildThread, pData,THREAD_PRIORITY_NORMAL,0,CREATE_SUSPENDED);
			m_pChildrenThread[x]->ResumeThread();
		}
	}
	m_EventEnd.SetEvent();
}

UINT CTestManualThreadDlg::ChildThread(LPVOID p)
{
	ChildThreadData *pData = (ChildThreadData *)p;
	pData->pDlg->ChildThread(pData->ThreadNumber);
	delete pData;
	return 0;
}
void CTestManualThreadDlg::ChildThread(int ThreadNumber)
{
	CString Test;
	m_pMainThread->SuspendThread();
	m_ChildSemaphore.Lock();
	g_childvar1++;
	Test.Format("%d", g_childvar1);
	m_ChildThread1.SetWindowText(Test);
	g_childvar++;
	Test.Format("%d", g_childvar);
	m_ChildThread2.SetWindowText(Test);
	m_ChildSemaphore.Unlock();
	m_pMainThread->ResumeThread();
}
void CTestManualThreadDlg::OnExit()
{
	
	m_EventEnd.SetEvent();
	::WaitForSingleObject(m_EventEnd.m_hObject, INFINITE);
	m_pMainThread->Delete();
	OnOK();
}

Posted 24-Jul-12 10:43am

FISH786

Updated 24-Jul-12 12:10pm

v2

Add a Solution

Comments

Sergey Alexandrovich Kryukov 24-Jul-12 16:51pm

What makes you thinking that this is the real reason for your memory leak?
--SA

FISH786 24-Jul-12 16:55pm

If I let the threads run without Semaphore and I pause the creation of the threads before I exit, I don't get memory leak, however my threads are not in sync. As soon as I use semaphore my threads are in sync but when I exit I get memory leak.

Sergey Alexandrovich Kryukov 24-Jul-12 16:53pm

And how do you create threads? (And what's your platform?) Windows thread API can create memory leaks; you need to use _beginthread, _beginthreadex.
--SA

FISH786 24-Jul-12 16:57pm

I am using AfxBeginThreads. I have been using it for a while. Not having any problems so far.

pasztorpisti 24-Jul-12 17:36pm

AfxBeginThreads() is an MFC API and the leak is probably some kind of resource MFC allocates for the management of threads, but the real problem is not the leak as SA pointed out. You can use any API, most of them are not having leaks (except old versions of CRT beginthread/endthread and some pthread libraries have known leak bugs - small and fixed in size on global storage so its not really harmful).

pasztorpisti 24-Jul-12 17:56pm

What kind of prog are you writing anyway? You bug is very common among ppl who just started multithreaded programming. I think we can help you with some good advices/techniques if the problem your code sovles is not a secret. :D Todays multithreaded programs are not that multithreaded, they can usually be made threading-bug-free with some simple design decisions.

FISH786 24-Jul-12 18:12pm

I have posted the code I am using... If there is anything I have missed would greatly appreciate the feed back(good or bad).

pasztorpisti 24-Jul-12 18:50pm

First a few good advices: Never use resumethread, suspendthread, and terminatethread!!!! Because: they help you to put bad multithreaded design in your code, and because some of the previously mentioned dangerous methods dont even exist on some platforms and in some threading libraries! If you need to create a suspended thread that you start by resuming it, then you can do that with normal createthread + an event primitive. all you need is createthread, wait for the thread and thats it.

If you have a subsystem that performs some kind of work for you and it makes the job with multiple threads inside, then your subsystem should have these methods: Start(), StartShutdownSequence(), WaitForShutdownSequenceToFinish().
Lets say you have 3 subsystems that work with threads (or maybe just one thread but that doesnt matter). When your program sarts you do this:
subsystem1.Start()
subsystem2.Start()
subsystem3.Start()

When you want to shudown you do this:
subsystem1.RequestShutdownSequence()
subsystem2.RequestShutdownSequence()
subsystem3.RequestShutdownSequence()
subsystem1.WaitForShutdownSequenceToFinish()
subsystem2.WaitForShutdownSequenceToFinish()
subsystem3.WaitForShutdownSequenceToFinish()

You could have only a simple ShutdownAndWait() method instead of RequestShutdownSequence() and WaitForShutdownSequenceToFinish() in each subsystem but notifying every subsystem at the same time ensures that these subsystems shutdown in parallel and not in a serial manner as if you called a ShutdownAndWait() method on every subsystem one-by-one. This can add up to painful seconds in a system with lot of threads. In your example you could go with the simpler ShutdownAndWait() solution for now. So: you always shutdown every subsystems and every threads inside them gracefully, by asking them politely to exit and by waiting for them! If you have a subsystem that uses another subsystem2 then you ask subsystem to shutdown and you wait for it, the subsystem is then asks subsystem2 to shutdown and waits for it. when the shutdown in subsystem2 has finished it returns to subsystem and then subsystem returns to you.

FISH786 24-Jul-12 18:57pm

Thank you. I will try that. :)

pasztorpisti 24-Jul-12 19:12pm

What I was described is mostly object oriented stuff, much easier to think this way if your problems are split into several objects. I usually start out solving the problem by finding out which classes I use (1 class for each subsystem/problem, usually this same class is the thread class if I use only 1 worker thread for the problem, I use a separate thread class if there are multiple threads involved in the subsystem.) Then you can continue by writing in your methods to the header part of the classes (building just the interface): subsystem::Start()... and so on. After this write in the implementation, use synchronization primitives to pass data/events between threads. You can also use an event queue implementation to give messages/work units to your worker threads. a blocking event queue is easy to use, it has 2 important methods: PutData() that is called by the producer/instructor/owner/whatever thread, it just puts in something to the queue and a GetData() that is called by the client thread - this GetData() returns one item from the queue, or blocks if the queue is empty until the producer thread puts in some data. The item in the queue can be for example a pointer to a job interface that has a virtual Run() method. This way your worker thread just does this in a loop: gets a job interface from the queue, and calls its Run() method. If the returned interface pointer is NULL it is a request to this worker thread to quit the loop and exit. This way other threads can derive arbitrary classes from the job interface and are able to issue any kind of work to the worker thread without hardcoding different tasks into the main loop of the worker thread with if-else.

Sergey Alexandrovich Kryukov 27-Jul-12 17:46pm

Absolutely good point about suspending and resuming thread!
As to thread termination, I hate to mention that (it can spark a flame war, actually), but there are some fields where this is absolutely unavoidable. After all, if you kill the process, all threads a killed by OS.

The problem is really deep. One day, I clearly realized that developers of the OS do not really understand the needs of some application. One guy from Microsoft invented the mechanism of exception seeding to replace TerminateThread, but this stoke of a genies was majorly ignored by the community, but later this mechanism was implemented in .NET Thread.Abort, which is also underestimated (if you know what you do, you can used it in 100% safe way, unlike TerminateThread), and Suspend and Resume thread was -- finally! -- deprecated.

--SA

pasztorpisti 27-Jul-12 18:05pm

I also hate to mention but I'm also using TerminateThread() in some circumstances. Crossplatform code forced me to avoid it but on windows I used it twice with good reason: I terminated the threads of a buggy third party library. :D This is just heavily watering fire. Another thing I dont like about TerminateThread() that it often creates hard to detect leaks (usually its TLS slots).
Thread.Abort: I'm a big fan of exception handling. I use it whenever I can. (Even when python scripting.) I'm always thinking about it as an "implicit error checking + return on error" after every function call - basically automatically generated code after every function call (this is how I usually explain exceptions to ppl who havent used it yet). I'm currently playing with C++ and unfortunately I don't really like the way this language "forces" its use on ppl. Another intersting thing is that on our performance critical code exception handling is usually turned off because of the generated "bloat code" that is harder to load to code cache.

Sergey Alexandrovich Kryukov 27-Jul-12 18:21pm

Do you want me to tell you about the exception seeding technique which you could use with C++ for Windows? It is 100% based on fully documented but non-portable Windows API? I implemented it on Delphi Pascal using the idea (sorry, cannot remember the name of the author of the method, it must be in my old records). You could have the functionality of Thread.Abort, but for umnanaged code.
--SA

pasztorpisti 27-Jul-12 18:31pm

Sure, "exception seeding" went out of my focus when I read your comment. Havent heared about it so your opinion about it is welcomed. Made me curious about how does it find a safe interrupt point in the code the thread is executing.

Sergey Alexandrovich Kryukov 27-Jul-12 20:22pm

Here. Explaining:

First, look here, GetThreadContext/SetThreadContext:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms679362%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680632%28v=vs.85%29.aspx

You see? You can get a thread execution context for any thread, modify it and set it for any thread (usually, a sure way to screw up a thread completely). The CONTEXT structure is non-portable (different for different instruction-set architectures, quite naturally), but the API is documented.

Now, how would I terminate a thread asynchronously? First, I would suspend it. The operation is unsafe generally, but perfectly safe if the thread is "scheduled for termination" like princess Leia (in our case, she will still have a chance to use her last will, which is the main point of all this activity :-). Now, when a thread is asynchronously suspended, there is a time to modify its CONTEXT. As this structure represents the CPU state, let's modify just instruction pointer (IP or whatever the particular processor has). You will need to modify the instruction pointer to make a jump to some method you write. Ignore method prolog, stack, everything, just jump. Normally, this would screw up everything, first of all the stack. When the context is mangled this way, I resume the thread.

Now, what is the situation when nobody cares about this stack? The only one: if you throw an exception in this method. This way, you don't care about the return -- it never happens. Define some exception like ThreadAbortException and throw it. The another previously remembered thread context will be found -- where? -- from the exception stack of the thread. Of course, the user should sandwich all thread methods with try-catch.

You only need to have a separate handle for that ThreadAbortException, but in fact, only if you need that if you need to express the "post-mortal" processing for the thread, a last will.

Can you see where the miracle comes from? Thanks to the already available exception mechanism, you asynchronously break the thread execution and brutally rip it out of context, but some valid context is restored from the last exception "try". You have a valid stack and context again, but not in the position where the thread can actually safely terminate itself. Everything else -- unclosed file buffers, blocking even handles, etc. -- it all can be put in order in the handler of the exception.

Knowing the idea, you can actually implement it all by yourself. And it makes clear why everything works smoothly with CLI. Basically, .NET code always has some part different for different instruction-set architectures (and with Mono also for different platforms). The mechanism I described is slightly different, but the idea and most of the code is the same.

So, what do you think? Do you agree that this is one of the greatest inventions?

To my shame, I was so very close to this solution, but failed to find if, mostly because I did not know about GetThreadContext/SetThreadContext. In 1993, I've written a fully-fledged multi-threading system based on 8088/8086 CPU, using inline assembly with object-oriented Borland Pascal. It was object-oriented multi-threading in first place, and it had a real-time options (scheduler, event handling were separate from the core, so I develop the method of thread switch which could be called from any hardware interrupt handler, which is a basis of real time). And last version of this library had fully-fledged structural exception handling, with no exclusions. So, I had full code to switch of thread context, good enough to understand all the mechanisms. But I failed to find an appropriate API hook in Windows. So, for a while, I used TerminateThread.

Damn! The text is cut... I'll continue in next post...
--SA

Sergey Alexandrovich Kryukov 27-Jul-12 20:31pm

...continued...

No wonder I'm a big fan of exception handling. At that time, it hasn't been yet introduced even in C++, was only in CLU and Ada. (And threads haven't been introduced in Linux yet.)
I worked enough in the fields where async. thread termination is a must: 1) hardware control system ("stop this machine-controlled thread this instance, no matter what that stupid OS things, otherwise it will crash into something..."), 2) running user's code under some frameworks; of course, the user should not guarantee to terminate thread (the user usually don't know about the thread) collaboratively; after all, Visual Studio (its run-time assembly host) will terminate the process under debugger, no matter what...

That's is. What do you think? This is something you can implement by yourself pretty soon. Any questions?

--SA

pasztorpisti 28-Jul-12 6:43am

Thank you for your extensive description! I know the related API from debug-host code and hacking. Was thinking about this whole topic for a while and I came to the conclusion that performing an Abort in C++ brings up several questions, probably that is the reason for the inventors not introducing this feature. In c++ its easy to write leaking code with this, and to make it more accurate unfortuantely its impossible to write correct code to use with Abort. For example if your thread has just allocated a piece of memory when abort comes then you are richer with a leak (you left inconsistent state inside a library shared among threds - the allocator lib). Basically the problem is that in the code the thread executes you can not introduce a so called "critical section" inside which Abort can't execute, and without this Abort would be very-very dangerous. Lest say my code controls a high performance laser cutter and Abort comes just after the code sent out the turn on signal to the hardware but before my variable that stores the on/off state havent been filled with the "on" value, in this case the finnaly block will not turn off the laser. :D Generalizing this: the thread can easily leave half finished work behind, corrupt state inside global libraries (allocator, laser-controller :D) in worst cases. I guess in managed code this isn't a problem to make Abort safe because of gc and the possibility of introducing the "critical section" thingy for "serious" system calls. Lot of problems can be managed if I start a process instead of a thread and I terminate the process in case of an error, this way I can rely on the ability of the operating system to recover and free up resources of my process, still it wouldn't necessarily turn off the laser cutter that is an "external resource" even for the OS so I'm also against TerminateProcess in such situations. Because of this reason I opt for well tested code and thread code in C++ that can be politely asked to finish.
Still the topic is very interesting and was pleasing to discuss plus it made me to do some brain gymnastics! :D

/OFF
The topic - exception handling, debug api, threading - has just reminded me to our fatal exception handling mechanism in C++ that was invented by one of my smart collegues. In our code we don't use exception handling because its not a good thing in C++ unfortunately, especially because of the two separate systems (seh, c++). We treat seh exceptions as fatal runtime errors where we want to bring up an exception window where the user can input text about what was happening before the exception and then this windows sends the crashlog to a server. we use unhandled exception filter for this. The trick is that we handle the exception on a totally separate thread that has no other functionality just receiving an excpetion notification and to handle it. You have to write its code bullet proof that is not hard because its a reasonably small piece of code. It is very useful to do this on a separate thread because how would you bring up an exception window if your gui thread had crashed or how would you send the crashlog if your network thread went to inconsistent state? :D This works even if the cause of the crash was a stack overflow because somewhere an article discussed this and a few function calls fit even in after a stack overflow on the crashed thread and later you have a big stack on the handler thread to do the work for exception handling.
/ON

Sergey Alexandrovich Kryukov 28-Jul-12 23:40pm

There could be multiple objections against Abort, which are also applicable to .NET. You see, that is advanced stuff, so every concern could be addressed one at a time. Abort can be made reliably only if certain additional conditions are observed, so this is reliable not for all threads, but for the certain subset of all thinkable threads and environments. It makes perfect sense, because considering all thinkable threads makes no sense; and this is because having some access to lower levels of programming, a lot can be screwed up, at least in the current process.

In particular, it is totally possible to make a totally reliable "critical section". Well, it is not a critical section, in fact. It should be a critical state of the thread when it temporarily should not be aborted. The idea is this: even though the abort itself should be fully asynchronous (this is the whole purpose), it can have the state where the abort is temporarily banned; and this can be cooperative (more exactly, it makes sense when this state is set by a thread).

One of the possible solution is: the Abort method should be encapsulated in a thread wrapper, and called only when allowed. The thread should setup the "abort ban" flag. First method is called by some other thread, and the second method (set/clear the flag) should be the private one of the thread wrapper. Now, the finished touch: both methods should be sandwiched in the lock on the same object (CriticalSection, in case of C++ for Windows).

If you consider this, you will see that it works correctly in all cases, but only if the wrapped thread (the one to be aborted) is implemented accurately. In particular, the flag should be set for short period of time and guaranteed to clear no matter what exceptions are. In this design, the abort would be simply deferred to the abort-save time.

Again, all the dangers of Abort should be weighted with the simple fact that there are important tasks where such Abort it totally unavoidable. If such safe (in certain strictly defined sense under certain conditions) Abort is not available, people having to solve those problem will call a brute-force TerminateThread, which is really unsafe. In other words, if in some OS the mechanism of asynchronous termination is either strictly impossible of unsafe; the OS is incorrect, not the tasks using such termination. I again say that the need of such abortion is highly underestimated by the authors of the OS.

--SA

Sergey Alexandrovich Kryukov 28-Jul-12 23:46pm

Buy the way, I'm just curious, did you work in laser machining? I did. Totally unrelated thing that my first major is Quantum Optics (laser machining laser specialists generally has no idea on what it is though), and I've done some works in that field.
--SA

pasztorpisti 29-Jul-12 8:14am

That brilliant! :D You are right about the critical section! If the thread is not in critical section then we can safely use the technique you mentioned in the first post, if its in criticalsection then we just setup a flag and the thread itself throws the exception in leavecriticalsection(). This can work! Still there would be so many functions to pack in criticalsections I would be afraid to use it in production code that is edited by lots of ppl. Too many spots for errors, still it might come handy some time that I know the technique! Thank you!
One of my bosses said something really wise about multithreaded design: We havent got so many cores/hardware threads these days so we can make use of them with a job system with the same number of threads as the cores/hyperthreads you have. Instead of running subsystems on separate threads in parallel its better to update subsystems in serial and each subsystem should do its job by packing its work into optimally sized jobs for the job system. This way you don't have to put lots of locks between your subsystems because only one systems uses the job system at a time plus this solution usually easier to scale depending on the number of cores, plus its more cache friendly to run only one system at a time. These jobs are simple and short in running time so you usually don't need to implement abort or polite exit. On the other hand you might want to start some other threads outside the job system for example for watching directory changes, networking but those are usually simple threads that arent busy most of the time and it is easy to impelment polite exit request in them. Sometimes simple programs consist only of trheads of the latter type, but in this case ppl have to find the right unit of work for the threads. I myself usually use only the above patterns that can be implemented without unsafe functions on each platform.

Yes I worked with lasers and it was fun! :) Worked on a cad system that controlled some high performance lasers cutting out metal components of other machines. The stuff was pure and simple, sending out control commands in text format on a serial port. :D Finally we rewrote the whole program because it was a 30yrs old codebase that was ported from unix to windows MFC!!!!!! It was a horror to add new features, plus it was the first and last C++ program I saw with every methods being static! :-) And were you working with lasers? Military research? ;)
Its interesting or maybe just a coincidence that I met quite a few coder professionals who found their coding talent after graduating from physics. How did you came into coding?

Sergey Alexandrovich Kryukov 29-Jul-12 15:32pm

I'm not into coding, this is not how I call it (well, do you believe there are effectively working coders these days?). During last years of my university (this is famous PhysTech, 6-years system) I've done some solid state physics and optics, experimental physics, with numerical simulation; and I came up with good ideas how to do the experiments, started working for development of controls systems for experimental research, later on I've been invited to the Institute of Nuclear Research, created a diagnostic network for the accelerator, the preview of technology used in contract work in Japan... and so on.
--SA

pasztorpisti 29-Jul-12 15:48pm

Somewhere I heared that 1 coder == 1 line of effective code/day. To be honest sometimes this is zero for me because we are chatting with the technical director all day about nothing code related. ;-)
Your research work sounds interesting! I worked on a medical research project at the university that analyzed monkey brain waves. :) Unfortunately that source was very low quality but tought me a lot of HOW-NOT-TOs. Maybe you have worked even with some military-COBOL! :D I read that companies working on research (including medical and military offices) usually have software in over 400(!!!) languages (are there so many languages???) sometimes in really poor quality because they never continued working on a codebase and everyone started his new work - read an article about failed medical and military devices. A defnese rocket system in iraq that has to be restarted every 8 hours because of accumulated errors over time impressed me... they had to find this bug by practice without QA... :-)

Sergey Alexandrovich Kryukov 29-Jul-12 21:58pm

Interesting information, I never heard about such things. (What the hell is military-COBOL? and how do you think could I even remotely be any close to such things?) Well, it all depends what do people call "research"...
--SA

pasztorpisti 30-Jul-12 6:00am

Sorry, military-cobol was just a joke. :) I don't assume anything like that from anybody. I kow that some ppl are very serious about this topic! Actually once I had an offer from a friend to go and program for the military in cobol (control systems of weapons) and this stuck in my head and always smiling about it when this comes to my mind. :-) Never coded a single line in cobol but they overlooked even that. They had (and probably have) legacy systems in that language, and the problems to solve were interesting (weapon control systems). Not to metion that the offered pay was very-very good, I just didn't want to get in touch with the government and the military because I'm afraid of them (dont want them to knock on my door :-D) plus don't like the things they would use my stuff for. Finally I stuck in game programming where I could solve similar interesting problems. :-) Wars are just totally needless things in the world in my opinion and I don't want to participate.

Sergey Alexandrovich Kryukov 30-Jul-12 9:36am

Never heard of it. US DOD organized creation of such a serious products as Ada (I wish people payed more attention for this language and experience; if it influenced more, we would have better situation now). And then, despite of some serious civil application of it (like transportation control systems in Europe, but not in US), the related job requirements included "security clearance", which is a big limitation. I do share your concerns about working for the military...
--SA

Sergey Alexandrovich Kryukov 29-Jul-12 15:40pm

Now, about "too many spots for errors". Of course you are right. That's why in complicated fields you cannot build up a secure system as most developers do, adding a piece to piece the natural way, with vague preliminary ideas. One should theoretically calculate the behavior in all cases, pretty much how it's done in mathematics, and then combine it with "natural growth", and later verify key things theoretically.

You know, Russian say: "To be afraid of wolves means not going into forest".

By the way, the proper Abort technology actually can reduce the risk. If would see it if you also take into account the human error. Without asynchronous termination, the code (cooperative) become more complex, and its more difficult to theoretically proof its correctness (remember Petri net?), and greater the change of developer's mistake. And again, cooperative termination means polling, which is evil.

--SA

pasztorpisti 29-Jul-12 15:59pm

One area I developed a lot during my professional years is writing "self correcting/fool proof code". :D This is something I couldn't learn as a hobby programmer at home. Lazy coders usually program by copy-pasting and modifying most of the time and you have to provide tools for these ppl.
Cooperative termination and polling in the worker thread can be quite safe. I always try to put a very small piece of work into the code of a thread and use the same patterns again and again so these days I make errors rarely in threading. I remember that I had a course (maybe system theory or something like that) that discussed petri nets, just haven't connected it with practical examples like threading. Still I wonder how often are these correctness proofing methods used in practice. Even nasa sent out devices to space with bugs in it!!! Havent they checked it with something like petri nets???

Sergey Alexandrovich Kryukov 29-Jul-12 21:54pm

This problem is a combination of social/cultural and objective scientific factors. Theoretical computer science is too far from many practical problems, and the situation is not easy to change. At the same time, with time, society shaped more or less stable social contract for development of lousy and fast software by crowds of unqualified people. The result is not really fast and not really inexpensive, but this is a self-reproducing system of relations...
--SA

pasztorpisti 24-Jul-12 19:02pm

There is also a big bug in CTestManualThreadDlg::OnExit(): after setting the event is has no point of wait for the event in OnExit(), you should wait for the main thread to terminate instead.

FISH786 25-Jul-12 9:13am

Thank you for your input. It's greatly appreciated. I guess I have work cut out for me. Any suggetion as to what book or a good article to read on threads?

I looked at a couple on here and was trying to create this small app to understand threads and syncrinization.

pasztorpisti 25-Jul-12 9:35am

Unfortunately I don't know any specific practical books/articles about this. I learnt it by working on existing systems and later on my own code that used threading. Most of the time very simple design can do the work (like the jobqueue I described above). If you have any specific task and don't know how to make it multithreaded you should ask it on codeproject. Practice is the best way to learn this.

1 solution

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 · 2012-07-24T11:00:00

Solution 1

This is a wrong approach. If you have threads stuck because they are waiting for each other forever, this is a problem called deadlock. It can be much more serious than your memory leaks. You should not aim to "release" them; you should prevent them. Please see:
http://en.wikipedia.org/wiki/Deadlock[^].

You can achieve this goal through accurate architecture and design of your system. One interesting and simple method of threaded system analysis is using the Petri net formalism. Please see:
http://en.wikipedia.org/wiki/Petri_net[^].

This excellent Microsoft article teaches us how to use it in practice:
http://msdn.microsoft.com/en-us/library/ms810303.aspx[^].

Now, let's come back to memory leaks. Nothing in your question tells me that you have detected the real reasons for your memory leaks. You should approach this problem from accurate diagnostics. You can use some development tool from the class of tools called "memory debugger". Please check the list of available memory debuggers found in this article:
http://en.wikipedia.org/wiki/Memory_debugger[^].

Good luck,

—SA

Posted 24-Jul-12 11:00am

Sergey Alexandrovich Kryukov

Comments

FISH786 24-Jul-12 17:04pm

Thank you. I will read on the articles.

pasztorpisti 24-Jul-12 17:49pm

+5 especially for the petri net part I didn't know and can come quite handy to teach stuff and to design.
One more thing I would add as an advice to the asker is to wrap the low level threading API (threads, synchronization primitives - criticalsection, event) into classes. This way you can replace the underlying api easily (easy porting to crossplatform), you can intorduce some printf() style oldschool debugging inside the methods of your classes, collecting statistics in the classes (how many threads are waiting for a lock, what is the spincount of a spinlock, etc...) that can also be used to debug and optimize your code. One thing I usually do is putting an assert to the destructor of my thread objects so that they fire if the destructor tries to execute before the encapsulated thread terminated. This usually helps me to catch a lot of bugs.

Sergey Alexandrovich Kryukov 24-Jul-12 18:11pm

Thank you for voting and -- absolutely great point about the wrappers; they can help same many problems at once. For example, I've published my thread wrapper code for .NET in couple of the answers; where it is even more powerful, because it also helps to avoid that pointless parametrized thread start method which requires type casting; and this is because the thread method can be an instance method, so the reference to the wrapper will be passed via "this" parameter; too bad this is not allowed in C++ threads, so just one problem would be passing a pointer to the wrapper to the thread.
--SA

pasztorpisti 24-Jul-12 18:21pm

Its completely possible in C++ as well! Every threading api I know allows passing in a (void*) parameter to its createthread() function! My threading classes ususally have a pure virtual Run() method (instance method). The thread interface I need is Start(), Wait(). There is another virtual method: OnFinished() that is executed after the thread object has changed to finished state - that is, the thread has finished executing the Run() method. I call the OnFinished() method in a fashion that it is valid to delete the thread object from there.

Sergey Alexandrovich Kryukov 24-Jul-12 18:24pm

I know, and this is how I did it. Again, wrapping the thread in a class is a very good idea.
--SA

pasztorpisti 24-Jul-12 18:30pm

I was almost sure I misunderstood the previous post. :D

FISH786 24-Jul-12 18:18pm

I am just starting to learn. I do appreciate the feed backs. I am kind basically self teaching trying to read samples and articles. :(... However it's all good. I hope I haven't missed anything in the code.. That was just a dummy tryout.

Sergey Alexandrovich Kryukov 24-Jul-12 18:26pm

Sure. I think most of us are self-taught. I hope you have enough information and food for thought, so you can consider accepting this answer formally (green button) -- thanks.
Wish you good luck,
--SA