Multi-threaded issues?

[Doomulation]

So, I was wondering if you all could help me out a bit...
I have a multi-threaded app which spawns threads to make sure the gui is responsive. However, this creates a load of issues. Most access violations occour which are random! Also some MFC functions spawn failed asserts, which leads me to believe that mfc really do not like multi-threaded apps to create new dialogs on different threads than the main one, and furthermore, not tot maniuplate and use these classes on different threads.

Then there's also lots of bugs if you want to test. I would realy appreciate if you could help me out a little with the source, as I will attach. If you modify anything, please let me know what you did, okay?

The app is in swedish, but it shouldn't be too much hassle for you fellow programmers out there. The comments and the language are still english.

 

[Cyberman]

Dreaded Threaded applications!

Doom:
1) your main thread MUST handle all GUI responses. Sorry that's the rules of using multiple threads within an applications. Don't violate this ever.
2) You must use thread synchronization functions to update the GUI from within the thread. This is the only valid and thread safe way.

Let's say for example you have a program that searches for data in a huge file. Let's say it's looking for PS1 tim files (since I'm familiar with this particular application). You need to send messages to start the thread. Once the thread is started you interaction between it and the main thread is limited by Synchronization calls. It's quite literally treated like another program with different application space. This is where the access violations are coming from.

While your thread is running anytime components need to update there information you need to have the 'search' thread send a synchronizing event to switch contexts and have a bit of code to handle the update. In my case I send information that needs to be added to a TreeView.

The main thread CAN affect certain variables that the alternate thread is using. In this case I use a variable called Running to stop the thread. It's not perfect, but as long as the variable is only inspected by the thread inside the thread loop, you won't have access violation issues.

Cyb

 

[Azimer]

Doom:
1) your main thread MUST handle all GUI responses. Sorry that's the rules of using multiple threads within an applications. Don't violate this ever.
2) You must use thread synchronization functions to update the GUI from within the thread. This is the only valid and thread safe way.
<snip>
Cyb

1) Incorrect. Any thread can handle GUI responses. It is dependant on the thread which created the GUI object. It is much more logical, however, to allow the CRT created thread to run the GUI.

2) GUI updates can be done asynchronously. The problem occurs when you have two things doing seperate things that only allow exclusive access. For example, DirectSound. You can not lock a sound buffer for writing and try to change its parameters from another thread.

In general, a GUI shouldn't need more than one thread for updating.

 

[Doomulation]

Hmmm, but your advice does not ring a bell.
Perhaps I need more synchronization, but I am unsure where. As far as I'm concerned, it should sync perfectly. The window object is not destroyed not destructed before all the threads it has spawned terminates.

 

[Cyberman]

Hmmm, but your advice does not ring a bell.
Perhaps I need more synchronization, but I am unsure where. As far as I'm concerned, it should sync perfectly. The window object is not destroyed not destructed before all the threads it has spawned terminates.

Do you have a 'Terminated' semaphor that you can inspect to see if threads have been terminated?
I started being very prudish about synchronization when I had my ap begin mysteriously expire. I suggest going through your thread code to be sure everything follows 'Thread Safe' operations. IE no thread is accessing another threads data without some form of careful synchronization or prevention of 'Deadly Embrace' issues. Keep GUI updates and functions in the main thread via synchronization. Yes Az is right you can do it in your thread, but to be honest, it's a bad practice and can lead to all sorts of obscure bugs, so I said DON'T do it. It's important to realize you are using 2 threads for a reason. It's also important to realize is you need to have both threads doing things. Trying to do all the nifty GUI updates within the spawned thread I've discovered leads to some really strange problems. So I stoped doing that. The important thing is to have the thread do only what it's ment to do, and the main ap do what it's ment to do. This is how I keep my application from crashing and not have threading issues.

Cyb

 

[Doomulation]

When a button is clicked, is spawns another thread to execute the code, so it can't really be done. It needs to access the gui, it needs to update the gui, etc.
I've also located some abnormalities, some of which I just cannot figure out. If you goto "Sök", "Lägg till / ta bort" under "Föräldrar" and then click "Lägg till" to add, when searching and select one to add, I do get some abnormalities.
One: I get an asset in RunModalLoop (ASSERT( ContinueModal() )) or, the whole window loses focus, like it's passing it on to a foreground window somehow. I tried to use SetFocus and BringWindowToTop APIs, but it doesn't seem to respond. Very weird. And that's where, I think, I also got an access violation once.

The app pretty much documents all the threads it spawns, and to which window it belongs. Then when the modal loop is completed, it will synchronize to see that all the threads it has spawned will terminate before destroying the window and destructing it. What's going on?

And there's the little old issue of window styles. I have a listbox which I would LIKE to switch between being able to select multiple items or just one. But it is not possible to switch between these after it has been created for some time. That's just stupid. I had to make a workaround. It can't be done in any possible way?

 

[Cyberman]

Since I don't use MFC or VC++ I can't directly answer you problems HOWEVER a guy on this board went into a long disertation on multithreadedness here is the thread it might help you sort your issues out or at least give you an idea of where to look.

As for your "I can't do it that way dang it" with your main and secondary thread, why can I do it and you can't? That's how my abuse of threads works. The thread only modifies a data set or provides synchronized updates to the GUI so that updates to the GUI specifically happen IN the GUI main thread. It also seems quite fast too. I am considering using more threads this way. I use VCL threading though, which handles a lot of the issues you have for you. Call me lazy?

Cyb

 

[Doomulation]

I will ponder what you write Let's see if I can find a solution to this madness.
EDIT:
That thread doesn't really help... I know of synchronization, but I don't need it in this project. It's a simple app. Only one threads runs along with the gui thread simteously, and they are independant on each other.
Most weirdness is just plain mfc-ish methinks. I haven't got an access violation since last. The lost focus issue still remains though. Odd.