Click here to Skip to main content
15,887,596 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
Hello,

I am working on an mfc dll that is accessed via a script and all this works fine. I have added a multi-threading component to it and am trying to use the WriteFile() function to write to my serial port, but somehow the WriteFile() function exits the application after the 2nd write command gets executed.

Without the multithreading bit, everything works normally and I can apply as many writefile commands as I want.

Multi-threading: I am using
CreateThread(NULL,0,WorkerThread,this,0,0);


to create my thread. Using "WorkerThread" to carry out the writefile operations described earlier in the background.

Additionally, I need to use the Sleep() function while writing it at intervals defined by me. At the moment, the program just quits when trying to use Sleep(). So, I just removed it for the time being but would need it at a later stage.

Is this a known problem or something with a but-obvious solution?

Update: I have sort of tried to reach somewhere close to the problem but still not been able to resolve it. Apparently it looks like there is some problem with my WriteFile() parameters.

WriteFile(theApp.m_hCom,&tBuffer,sizeof(tBuffer),&iBytesWritten,NULL);


It is not taking the sizeof(tBuffer) properly and because of which it is crashing. I checked out the string to be passed, which is exactly equal to what I need to pass but its crashing out the program if I write the code as done above (for WriteFile()). When I keep the stringlength i.e. manually set the sizeof(tBuffer) parameter to 14, then the program runs but the command does not get executed as the total string size of buffer is 38. Urgently need help on this.

Kindly let me know.

Thanks in advance.
Posted
Updated 23-Sep-11 3:14am
v3

This is a classic producer/consumer problem that needs synchronization to make it work properly. It's just like in real life, it is impossible to write both at the same time using just one pencil. You need to make rules about sharing or make one person responsible for writing stuff down.

Check out the link for more info:
http://msdn.microsoft.com/en-us/library/aa645740%28v=vs.71%29.aspx[^]

Good luck!
 
Share this answer
 
v3
Comments
Mobile.Instinct 23-Sep-11 9:14am    
Hello, I have improved my question. Do you have any suggestions in this regard?
CPallini 23-Sep-11 9:23am    
You should follow the advice and do proper synchronization (for instance do both threads access tBuffer?)
Mobile.Instinct 23-Sep-11 9:32am    
Sorry, I am really new to threading. How do I check whether both threads access tBuffer or not?
E.F. Nijboer 23-Sep-11 10:54am    
Most simple method could be to add a lock around it, like this:
void myWriteFile() {
lock(writeLockObject) {
WriteFile ...
}
}

This way it will allow only a single thread but they must both call the same method myWriteFile. If they both open the file or use the file handle on their own then they won't be using the same lock object meaning it doesn't have any affect. In that case you could use a mutex because it is a locking mechanism usable in this scenario. You can create a mutex multiple times with the same name and that will be the same global locking object. Nowadays there is a great collection of locking mechanisms all to make it as easy as possible and most of them to help prevent deadlock and starvation. I do think sometimes that all this diversity can be quite confusing when beginning concurrent programming. So the best thing is to start with the basics because that will make it all a lot easier. you will then be able to see through all of those mechanisms more easy and understand how it is done. They all use the basics. I think it would be wise to first read up on those basics like the semaphore, mutex and critical section. You will soon find out that the last two mentioned can or could also be traced back to the first, the semaphore. The wiki is a good start on this:
http://en.wikipedia.org/wiki/Semaphore_%28programming%29

Also, check out this link with some nice examples:
http://www.albahari.com/threading/part2.aspx#_Mutex

Hopefully this will get you started on fixing the problem and also to get in on the basics of it all. It can be somewhat hard at first but will get better quick. It also helps visualize synchronization with how it would be done in real life. Like for example the occupied sign when you go showering can be considerd a semaphore. Shouting at your girlfriend that you're done and she can now take a shower can be considered signaling. She could also just be waiting just outside the door waiting for you to be done, and that is just what a monitor does. Maybe this tip is helpful as well. :-)
Schehaider_Aymen 25-Sep-11 18:45pm    
Using multithreading is quite complexe specially when you treate problems like producer/consummer. As Nijboer said u have to use synchronisation by locking and unlocking the shared ressources . u may find some examples in the MSDN.
Well, I finally got it working. I am not sure how this works but some trial and errors made it work. The main understanding behind this is still unknown.

I was running my DLL via the Debugger option available in Visual C++, giving it an access to the command prompt and allowing it to run my script on compiling the DLL in order to debug my program. It seems like Visual C++ did not like the idea and kept on crashing when trying to do it that way.

When I tried accessing the DLL just by the python script, a few tries here and there made it work like a beauty. Seems like there was no problem with the Write() function but with the fact that I was running it via the Debugger and did not try it with just the script.

I know I haven't mentioned about my script in my question but I was assuming it had something to do with my thread as I am just a beginner in threading.

Thanks guys for your replies. Was really helpful to actually understand the whole concept of multithreading.
 
Share this answer
 

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