In all the confusion from the discussion earlier today you're partly forgiven, but consider the following for spawning the worker thread:
// Create thread suspended to avoid race conditions
pThread = AfxBeginThread( run, this, 0, 0, CREATE_SUSPENDED, NULL );
// Make sure the thread could be created and // the pointer is valid before operating on itif( pThread )
// Don't let the object delete itself since we want // to be able to wait on the thread handle// This is important and addressed in the article linked to by Carlo!
pThread->m_bAutodelete = FALSE;
What kind of event stops the worker thread from running?
The way I interpret your destructor is that the thread does its job and then terminates by itself.
What does the thread do? Your comment "display the data" worries me since you should not touch the GUI from a worker thread in order to avoid deadlocks.
Probably you shouldn't be using multithreading at all for the problem you're trying to solve, since you seem to be doing thing sequentially and not in parallel.
Your destructor doesn't really make sense. There's also a race condition that in most cases would generate an exception when you're trying to free memory that has already been freed since you haven't set m_bAutoDelete to FALSE. You're mixing manual and automatic deletion of the CWinThread object.
You should also make sure all thread spawned by your program are terminated before allowing the program to exit. It's considered Best Practice because when you exit your program you don't have the power to do anything about it any longer.
The most harsh way the code that waits for the thread to exit could be like this:
if( pThread )
// Here should probably be something that tells the thread // to stop executing such as an event that is signalledif( ::WaitForSingleObject( pThread->m_hThread, INFINITE ) == WAIT_OBJECT_0 )
// Now it's safe to delete the CWinThread object!
pThread = NULL;
You need to get back to the article and read it again as the above suggests that you haven't read it carefully enough and apparently have not understood it properly.
Believe me, I've suggested Joe's article to fellow programmers since he wrote it almost a decade ago. In my opinion it's the best article that can be found on the internet describing multithreading, especially together with MFC framework.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote "High speed never compensates for wrong direction!" - unknown
You need two CEvent objects, one representing the request from the primary thread to stop, and the other representing the acknowledgment from the secondary thread that it has stopped. When the primary thread responds to a stop request (e.g., Alt+F4, X, Cancel), it signals the first event and then waits for the second event. In the secondary thread, call WaitForSingleObject() on that event with 0 as the wait time. If it comes back as signaled, signal the other event.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
I am not able to use C# Managed DLL into my VC++ Application (DLL).
Below are the steps I am doing but with no success.
1. Copied C# DLL into the folder where all my lib files reside.
2. Included #using :GT:JPEGMaker.dll:LT: statement into stdafx.h file
3. After this I got an error message regarding CLR Support, so I enabled the same in project settings.
4. After this I got a linking error...
:GT: Greater Then Sign
:LT: Less Then Sign
Please provide details or Do I need to convert C# DLL into Native DLL?
There is no one 'best font' for any language. If you are writing an Unicode application, the Devnagari script would be displayed automatically (by default) with Mangal. You need not worry about fonts, if you are working on an Unicode aware application.
It is a crappy thing, but it's life -^Carlo Pallini
When VC++ "LineTo" statement is called very often (say every 100 ms), it is using more resource and it is not getting released. If my application is running for longer period (say 2 hours), high usage of resource problem causing more RAM usage and memory is not getting released and growing continuously.
Sample code is given below (Please send your personal email id, so that I can email complete code)
I don't know exactly why you encounter a memory leak, but one think that is sure is that you are doing it the wrong way: you should never access your user interface from a separate thread (which is what you are doing here). This is not the way to do it. Instead, in a separate thread, you can add data in a std::vector (for instance) which is protected against multi-threading access and then you send a message to the UI to refresh itself. The UI will then (in the main thread) extract information from the vector and draw the additional points.
I don't know if this will fix your problem but this is something you'll have to fix or you'll encounter problems in the future.
I don't think LineTo() causes high usage of resource&RAM. You are exactly doing it in wrong way.
Firstly, you need to understand the callback function of a timer in VC can be re-called while previous call is not completed yet. Basically, each callback will create a thread.
Secondly, I don't understand why you create a thread in the callback function, which will lead to run many threads at the same time.
So i think running many threads at the same time causes your problem.
If you want to update you UI, you can set a timer or a thread in your UI class which gets data and draw them on UI periodically. Meanwhile, there is another thead to prepare those drawing data.
Welcome to www.softwaretree.net!
This website is generated completely by static html pages transforming technology.
You can find many excellent audio/video tools there!
The program is to keep records and perform statistical for a class of students.
the class may have up to 40 students. They have 5 quizzes, and all the students are identified by a 4 digit student number
and the program will print the students scores and calculate and print the statistics for each quiz
I am having a c++ file which is used to create mexfunction DLL that can be used to call a function from Matlab through dll. This is used to compute some mathematical calculations on a big matirx and for this I do it in two parallel threads each doing half matrix. At the end I combine both to generate full resultant matrix. For this, I create two different threads as follows-
Everything is fine and good while doing as above and I used this for a long time without any problems. Now I am planning to make this more efficient by making it multithreading adaptable to the processor on which it runs. I have couple of systems which are like 4core/8core and would like to create threads dynamically. I came up with the following idea and implemented it and guess what it gives fatal errors while running and I highly suspect the way I am creating multiple threads.
DWORD WINAPI GenerateThread(LPVOID param);
void CreateResult(unsigned int idx);
//read in input params//find (#processors*#logicalprocs*#coresperproc)=m_nThreads;
thd_handle = new HANDLE[m_nThreads-1];
//CreateThreadsfor (unsigned int i=0; i < m_nThreads-1; i++ )
thd_handle[i] = CreateThread(NULL, GenerateThread, &i, 0, NULL);
//prepare result//return result to matlab
DWORD WINAPI GenerateThread(LPVOID param)
DWORD iter = *(DWORD*)param;
void CreateResult(unsigned int idx)
//compute result for this matrix size depending on idx
if I use the dll generated from this code, the program crashes... am I doing something fundamentally wrong here?? is there any other better way to achieve this??
A thread in an executable that calls the C run-time library (CRT) should use the _beginthreadex and _endthreadex functions for thread management rather than CreateThread and ExitThread; this requires the use of the multi-threaded version of the CRT. If a thread created using CreateThread calls the CRT, the CRT may terminate the process in low-memory conditions.
You pass a pointer to a stack variable in the CreateThread call. That's not a great idea - you can't guarantee that the newly created thread will assign to iter before i changes. Why not just pass the value of i rather than the address. Even though the param is an LPVOID, integer is convertible to LPVOID and vice versa.
One other thing - why use m_nThreads-1 all over the place - once your main thread enters WaitForMultipleObjects, there will be m_nThreads cores available for processing, as the WaitForMultipleObjects call will yield the core it's on.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Last Visit: 31-Dec-99 19:00 Last Update: 8-Feb-23 9:42