If applications need to be thread-safe, simple boolean switches won’t be enough (Cyberman’s method isn’t the type of simple boolean switch I mean when I say that; I am just saying it to be clear).
Consider this code that could be called on two separate threads:
void CoolClass::DoNeat() {
while ( m_bLock ) {} // Wait for this function to stop being called in the other thread.
m_bLock = true;
delete [] m_pArray;
m_pArray = new Cool[235];
m_bLock = false;
}
Although the case can be rare, it can happen where the lock is set twice.
Consider what would happen if Thread1 gets to “while ( m_bLock ) {}†and sees there is no lock, so it goes on.
Thread1 then does this:
MOV EAX, 1 ; Move the “bool true†into EAX before putting it into m_bLock. Some compilers generate this type of code and you shouldn’t assume it will generate something like “MOV m_bLock, 1†where it moves “true†into “m_bLock†directly.
Then Windows halts it and lets Thread2 resume.
Thread2 goes into the function and sees m_bLock is false, skips the while, sets m_bLock to true, and calls the “delete [] m_pArray†line.
Then Thread2 is halted and other threads get to go.
Both threads managed to get into the function at the same time.
Thread1 continues, sets m_bLock to true (already set by Thread2 anyway), then deletes the array.
Throws an exception because Thread2 just deleted the array and didn’t yet have time to renew it.
If you want to ensure your program is thread-safe, you need to use critical sections.
They are quite simple to use and they are made for just this type of thing.
Let’s give CoolClass a new member:
CRITICAL_SECTION m_csCritSection;
Initialize it in the constructor:
CoolClass::CoolClass() {
InitializeCriticalSectionAndSpinCount( &m_csCritSection, 0x80000400 );
}
Destroy it in the destructor:
CoolClass::CoolClass() {
DeleteCriticalSection( &m_csCritSection );
}
And modify our function to use it:
void CoolClass::DoNeat() {
EnterCriticalSection( &m_csCritSection );
delete [] m_pArray;
m_pArray = new Cool[235];
LeaveCriticalSection( &m_csCritSection );
}
That’s it.
When you enter the “m_csCritSection†object, no other thread can enter it until you leave it.
When our first thread enters it, the other thread will come along and try to enter it also, but Windows will ensure that only one thread can be in it at a time.
The other thread is forced to wait until we call LeaveCriticalSection( &m_csCritSection ); in our first thread.
Alhexx, although you will certainly need two threads (one to maintain keyboard input/distribute Windows messages, and ensure the user can press Cancel, and another to actually perform the extraction operation), you will probably not need to go into critical sections or perform any other thread-related synchronization UNLESS you have any other threads accessing the extraction thread’s resources while it is extracting.
What I mean is:
If you have one thread for handling user input (for the cancel button) and that is all that thread does, then you do not need to use thread synchronization (I will explain why after this).
But if your input-handling thread (or any others) are reading information from the extraction thread’s resources (for example to show the user progress) then you need to create clever locks/unlocks on those resources using critical sections.
However, I don’t think you will need any critical sections at all.
Here is the plan I would suggest (similar to Cyberman’s but a few more details):
You create a second thread to handle the extraction, leaving your main thread available to continue accepting input.
You will store all your information into a structure or class while you extract, so give that structure or class a member called “m_bCancelâ€.
When the extraction begins it is set to false.
When you hit the button, it is set to true.
Then your extraction thread checks it whenever it is ready and if it is true, it finishes extracting and closes.
Changing the flag from false to true happens on a thread that is not the extraction thread obviously, but synchronization is not needed because the extraction thread just checks it when it wants. the checking of the flag only happens on the extraction thread, and ensures that the extraction thread can properly finish its current task and close properly.
If you want to show the user your current progress, the extraction thread will handle this.
When the extraction thread has something new to show the user, it simply shows it and continues with the next file.
This means your outside threads are not trying to pear into your extraction thread for information that may or may not be accessible at that time.
You can give the structure/class used for extraction another member which will allow it access the update dialog directly (HWND m_hWnd for example) and then it updates on its own.
A second note, when using a second thread to extract the files, it is recommended that you not terminate it from another thread.
It should have its own termination routine which frees any resources it was using from the extraction process (which I assume would be a lot) and then calls “ExitThread( 0 )†to terminate itself.
This “CoolClass::FreeResourcesAndClose()†function would be called when the extraction thread detects that its m_bCancel member has been set to true.
But there is one last thing to do.
This thread is actually going to close your “Extracting, Please Wait…†dialog (or whatever dialog you are using that allows the user to cancel).
CoolClass::FreeResourcesAndClose() should send a message to that dialog (which as you recall is a member of our structure/class [m_hWnd]) to close it.
So inside the CoolClass::FreeResourcesAndClose() function you would have this line:
EndDialog( m_hWnd, 0 );
Again, don’t have to worry about threading issues here.
This will send a message to that dialog telling it to close, which your main thread will handle when it is ready (in your message pump, where all Windows messages go and wait to be handled).
If you don’t want it to just close, you can define your own user message:
#define WM_NOTIFYENDOFEXTACTION WM_USER + 0x01
Then send that message to the dialog via SendMessage() and handle it in the dialog’s message handler.
L. Spiro
OTHER USEFUL HINTS:
You can save a few instructions by calling CreateRemoteThread( -1, … ) instead of CreateThread(). CreateThread() only calls CreateRemoteThread() with the hHandle parameter set to -1. Of course you won’t be calling CreateRemote thread in a loop but it is interesting information anyway.
CreateThread()/CreateRemoteThread() allow one parameter to be passed to the new thread.
This may seem as though it is not enough in some cases, but remember you can pass the address of a structure, and that structure then has additional information you want to pass to the thread.
You can (and should) create a structure that has all the parameters you want to pass to the thread (options for example).
But be careful with how you do this.
The structure can not be created on the stack. You have to use “new†so that the second thread can access it “when it is readyâ€.
If the creation of the new thread fails, your first thread must “delete†this object on its own.
If the new thread is created correctly, the first thread can continue, and the new thread will then be responsible for “deleteâ€ing the structure after it is done with it.
struct ExtractParms {
int iWidth, iHeight;
unsigned long ulDaysInyear;
};
void CreateExtractionThread( int iWidth, int iHeight, unsigned long ulTotalDaysInTheYear ) {
ExtractParms * pexpParms = new ExtractParms();
pexpParms->iWidth = iWidth;
pexpParms->iHeight = iHeight;
pexpParms->ulDaysInyear = ulTotalDaysInTheYear;
HANDLE hThread = CreateThread( NULL, 0, (LPTHREAD_START_ROUTINE)ExtractRoutine, (LPVOID)pexpParms, 0, NULL );
if ( hThread == NULL ) {
delete pexpParms;
}
}
DWORD WINAPI ExtractRoutine( ExtractParms * pexpParms ) {
if ( pexpParms->ulDaysInyear == 0 ) {
delete pexpParms;
return 0;
}
delete pexpParms;
return 1;
}
