WM_TIMER? - (semi real time) - (I'M VERY NOVICE) - (4 short questions)
-
Hello, first of all let me thank you for reading those 4 short questions, for your time and help. >> INTRODUCTION: I have to read and write information from a non thread safe DLL very often, imagine that we are talking about obtaining real time information from that DLL. This DLL allow me to get errors, coordinates, what's happening in general... and set values to var's of/from another program. I'm using WM_TIMER messages to get this information and each 10ms. the information is required. >> QUESTIONS: 1. What could happen if the WM_TIMER message handling time is bigger than the 10ms.? 2. Is there any way to discard the messages received while one message is being handled? 3. The information required from the DLL should be as recent as it could be, is this the most correct way of working? 4. Is there any other way of requiring information continuously without getting the processor performance seriously affected? Thank you very much.
AFAIR, Windows will not fill your message queue with WM_TIMER when you're processing them slowly. Regarding questions 3 and 4: Describe your application in more detailed fashion. Since you're worried about processing times longer than 10ms, the problem may be with slow display of information. Tomasz Sowinski -- http://www.shooltz.com
-
Hello, first of all let me thank you for reading those 4 short questions, for your time and help. >> INTRODUCTION: I have to read and write information from a non thread safe DLL very often, imagine that we are talking about obtaining real time information from that DLL. This DLL allow me to get errors, coordinates, what's happening in general... and set values to var's of/from another program. I'm using WM_TIMER messages to get this information and each 10ms. the information is required. >> QUESTIONS: 1. What could happen if the WM_TIMER message handling time is bigger than the 10ms.? 2. Is there any way to discard the messages received while one message is being handled? 3. The information required from the DLL should be as recent as it could be, is this the most correct way of working? 4. Is there any other way of requiring information continuously without getting the processor performance seriously affected? Thank you very much.
- Nothing could happen, besides that the update would occur less frequently. However, I believe 10 ms is too frequent if the update is made only for updating a GUI. It could probably be 250 ms (a quarter of a second), or even higher. 2/3/4) Using a WM_TIMER message to pull information is an old fashion, "16-bit" type solution, which, as you've noticed, usually affects performance. While it is possible to discard intermediate messages that have arrived during processing of another (by using the message filtering parameters of PeekMessage to remove such messages), it would be better to implement a push design in the DLL. If you have the DLL's source code, you could change it to signal a kernel object (such as an event) as soon as new information is available. The event would typically be created by the consumer application, and be supplied to the DLL through some initialization function. The application would then wait on this object to become signaled, either in a separate worker thread (the better choice since it wouldn't lock up the GUI during update processing), or in its main thread by using MsgWaitForMultipleObjects (in order to allow for window message processing). When signaled, the application should do whatever needs to be done for retrieving data from the DLL and updating the user interface, then return and wait for another update to occur. This way, the update thread will only be active when new data is available (which could be after 5 ms or 15 minutes). If you need to limit the update interval (i.e., data is sometimes available more often than you'd like to update the GUI), you could create a WaitableTimer object with say a 50 ms interval, and let the thread wait for both the update event and the timer object to become signaled (WaitForMultipleObjects with bWaitAll = TRUE). This way the update cannot begin until the wait interval has expired even if data is available. Good luck!
-
AFAIR, Windows will not fill your message queue with WM_TIMER when you're processing them slowly. Regarding questions 3 and 4: Describe your application in more detailed fashion. Since you're worried about processing times longer than 10ms, the problem may be with slow display of information. Tomasz Sowinski -- http://www.shooltz.com
Hello, first of all, let me thank you for your interest. Tomasz Sowinski wrote: Describe your application in more detailed fashion Here's the description: My MVC++6 app. is only a GUI for another program (let's call it XProgram). XProgram is a program that controls the movements of a machine it allows me to move motors, read positions with encoders, activate and deactivate actuators and read sensors state. The DLL that I have is supplied with XProgram and it allow me to get access to what I will call an "adress" this adress can contain a value of any type (string, double, float, integer...) then I use that DLL to get and to store information from/to the XProgram. I'm worried because of the fact that if anything fails the machine can stop working, or even worse, it can wound somebody. The only way that I have to work is to continuously ask for the values that have to be shown, and I would like to get the best way of doing it without recompiling the code in each machine. Moreover, I would like to work as in a realtime app. discarding the messages that cannot be processed because another message of the same type is being processed. Of course I'm still very novice, and now you know more about the way of working of my program, and about my problem too. Then, if you know another solution that can be a good deal for me, please, tell it to me. SUMMING UP: I obtain and send information to XProgram from my GUI program using a DLL. I need this to be fast. I need the processor as free as it would be possible (in order to let XProgram work). Thank you very much.
-
Hello, first of all, let me thank you for your interest. Tomasz Sowinski wrote: Describe your application in more detailed fashion Here's the description: My MVC++6 app. is only a GUI for another program (let's call it XProgram). XProgram is a program that controls the movements of a machine it allows me to move motors, read positions with encoders, activate and deactivate actuators and read sensors state. The DLL that I have is supplied with XProgram and it allow me to get access to what I will call an "adress" this adress can contain a value of any type (string, double, float, integer...) then I use that DLL to get and to store information from/to the XProgram. I'm worried because of the fact that if anything fails the machine can stop working, or even worse, it can wound somebody. The only way that I have to work is to continuously ask for the values that have to be shown, and I would like to get the best way of doing it without recompiling the code in each machine. Moreover, I would like to work as in a realtime app. discarding the messages that cannot be processed because another message of the same type is being processed. Of course I'm still very novice, and now you know more about the way of working of my program, and about my problem too. Then, if you know another solution that can be a good deal for me, please, tell it to me. SUMMING UP: I obtain and send information to XProgram from my GUI program using a DLL. I need this to be fast. I need the processor as free as it would be possible (in order to let XProgram work). Thank you very much.
Joan Murt wrote: I need the processor as free as it would be possible (in order to let XProgram work). This may be difficult, if you don't have the access to DLL code. In such case, you can only repeatedly check the values, which always results in high CPU usage. If you have the access to DLL code, you can use various synchronization objects, just like Carl pointed out in his reply. Tomasz Sowinski -- http://www.shooltz.com
-
- Nothing could happen, besides that the update would occur less frequently. However, I believe 10 ms is too frequent if the update is made only for updating a GUI. It could probably be 250 ms (a quarter of a second), or even higher. 2/3/4) Using a WM_TIMER message to pull information is an old fashion, "16-bit" type solution, which, as you've noticed, usually affects performance. While it is possible to discard intermediate messages that have arrived during processing of another (by using the message filtering parameters of PeekMessage to remove such messages), it would be better to implement a push design in the DLL. If you have the DLL's source code, you could change it to signal a kernel object (such as an event) as soon as new information is available. The event would typically be created by the consumer application, and be supplied to the DLL through some initialization function. The application would then wait on this object to become signaled, either in a separate worker thread (the better choice since it wouldn't lock up the GUI during update processing), or in its main thread by using MsgWaitForMultipleObjects (in order to allow for window message processing). When signaled, the application should do whatever needs to be done for retrieving data from the DLL and updating the user interface, then return and wait for another update to occur. This way, the update thread will only be active when new data is available (which could be after 5 ms or 15 minutes). If you need to limit the update interval (i.e., data is sometimes available more often than you'd like to update the GUI), you could create a WaitableTimer object with say a 50 ms interval, and let the thread wait for both the update event and the timer object to become signaled (WaitForMultipleObjects with bWaitAll = TRUE). This way the update cannot begin until the wait interval has expired even if data is available. Good luck!
Hello, first of all let me thank you for your answer. ----------------------------------------------------------------------------- DESCRIPTION OF THE WORKING METHOD: ----------------------------------------------------------------------------- My MVC++6 app. is only a GUI for another program (let's call it XProgram). XProgram is a program that controls the movements of a machine it allows me to move motors, read positions with encoders, activate and deactivate actuators and read sensors state. The DLL that I have is supplied with XProgram and it allow me to get access to what I will call an "adress" this adress can contain a value of any type (string, double, float, integer...) then I use that DLL to get and to store information from/to the XProgram. I'm worried because of the fact that if anything fails the machine can stop working, or even worse, it can wound somebody. The only way that I have to work is to continuously ask for the values that have to be shown, and I would like to get the best way of doing it without recompiling the code in each machine. Moreover, I would like to work as in a realtime app. discarding the messages that cannot be processed because another message of the same type is being processed. Of course I'm still very novice, and now you know more about the way of working of my program, and about my problem too. Then, if you know another solution that can be a good deal for me, please, tell it to me. SUMMING UP: I obtain and send information to XProgram from my GUI program using a DLL. I need this to be fast. I need the processor as free as it would be possible (in order to let XProgram work). ----------------------------------------------------------------------------- >> NOTE Carl Berg wrote: it would be better to implement a push design in the DLL. I don't have access to the DLL code. >> QUESTION Carl Berg wrote: While it is possible to discard intermediate messages that have arrived during processing of another (by using the message filtering parameters of PeekMessage to remove such messages) I have taken a look to the MSDN and I have not seen how to eliminate the same message that is being processed from the messages queue. Could you give me an example (a little one) of how to do it? Thank you in advance.
-
Hello, first of all let me thank you for your answer. ----------------------------------------------------------------------------- DESCRIPTION OF THE WORKING METHOD: ----------------------------------------------------------------------------- My MVC++6 app. is only a GUI for another program (let's call it XProgram). XProgram is a program that controls the movements of a machine it allows me to move motors, read positions with encoders, activate and deactivate actuators and read sensors state. The DLL that I have is supplied with XProgram and it allow me to get access to what I will call an "adress" this adress can contain a value of any type (string, double, float, integer...) then I use that DLL to get and to store information from/to the XProgram. I'm worried because of the fact that if anything fails the machine can stop working, or even worse, it can wound somebody. The only way that I have to work is to continuously ask for the values that have to be shown, and I would like to get the best way of doing it without recompiling the code in each machine. Moreover, I would like to work as in a realtime app. discarding the messages that cannot be processed because another message of the same type is being processed. Of course I'm still very novice, and now you know more about the way of working of my program, and about my problem too. Then, if you know another solution that can be a good deal for me, please, tell it to me. SUMMING UP: I obtain and send information to XProgram from my GUI program using a DLL. I need this to be fast. I need the processor as free as it would be possible (in order to let XProgram work). ----------------------------------------------------------------------------- >> NOTE Carl Berg wrote: it would be better to implement a push design in the DLL. I don't have access to the DLL code. >> QUESTION Carl Berg wrote: While it is possible to discard intermediate messages that have arrived during processing of another (by using the message filtering parameters of PeekMessage to remove such messages) I have taken a look to the MSDN and I have not seen how to eliminate the same message that is being processed from the messages queue. Could you give me an example (a little one) of how to do it? Thank you in advance.
You can remove WM_TIMER messages like this at the end of your data polling function: // Look for WM_TIMER messages MSG msg; while ( ::PeekMessage(&msg, NULL, WM_TIMER, WM_TIMER, PM_NOREMOVE) ) { // m_nTimerID contains holds the ID of your timer... if you're using // more than one timer, this removal procedure won't be fool proof. if ( msg.wParam == (UINT)m_nTimerID ) { // Remove the message ::PeekMessage(&msg, NULL, WM_TIMER, WM_TIMER, PM_REMOVE); } else break; }; However, I wouldn't implement it like this, but instead create a worker thread that uses a Waitable Timer object (cf. CreateWaitableTimer in the Platform SDK). This way you needn't worry about removing messages from the queue, and you can change the worker thread's priority if you like. You will need to synchronize access to the variables you will be updating, but it isn't that hard. HANDLE hWait = ::CreateWaitableTimer(...); for ( ;; ) { ::SetWaitableTimer(...); // You might want to use a "Quit" event object as well, created and signaled from the main thread, so you know when to exit the thread. If that's the case, use WaitForMultipleObjects instead. DWORD dwWaitRet = ::WaitForSingleObject(hWait,...); switch (dwWaitRet) { // cases... } } CloseHandle(hWait);
-
You can remove WM_TIMER messages like this at the end of your data polling function: // Look for WM_TIMER messages MSG msg; while ( ::PeekMessage(&msg, NULL, WM_TIMER, WM_TIMER, PM_NOREMOVE) ) { // m_nTimerID contains holds the ID of your timer... if you're using // more than one timer, this removal procedure won't be fool proof. if ( msg.wParam == (UINT)m_nTimerID ) { // Remove the message ::PeekMessage(&msg, NULL, WM_TIMER, WM_TIMER, PM_REMOVE); } else break; }; However, I wouldn't implement it like this, but instead create a worker thread that uses a Waitable Timer object (cf. CreateWaitableTimer in the Platform SDK). This way you needn't worry about removing messages from the queue, and you can change the worker thread's priority if you like. You will need to synchronize access to the variables you will be updating, but it isn't that hard. HANDLE hWait = ::CreateWaitableTimer(...); for ( ;; ) { ::SetWaitableTimer(...); // You might want to use a "Quit" event object as well, created and signaled from the main thread, so you know when to exit the thread. If that's the case, use WaitForMultipleObjects instead. DWORD dwWaitRet = ::WaitForSingleObject(hWait,...); switch (dwWaitRet) { // cases... } } CloseHandle(hWait);
What are advantages of CreateWaitableTimer over plain Sleep call? Tomasz Sowinski -- http://www.shooltz.com
-
Hello, first of all let me thank you for reading those 4 short questions, for your time and help. >> INTRODUCTION: I have to read and write information from a non thread safe DLL very often, imagine that we are talking about obtaining real time information from that DLL. This DLL allow me to get errors, coordinates, what's happening in general... and set values to var's of/from another program. I'm using WM_TIMER messages to get this information and each 10ms. the information is required. >> QUESTIONS: 1. What could happen if the WM_TIMER message handling time is bigger than the 10ms.? 2. Is there any way to discard the messages received while one message is being handled? 3. The information required from the DLL should be as recent as it could be, is this the most correct way of working? 4. Is there any other way of requiring information continuously without getting the processor performance seriously affected? Thank you very much.
You should probably read this article: http://www.codeproject.com/system/simpletime.asp
-
What are advantages of CreateWaitableTimer over plain Sleep call? Tomasz Sowinski -- http://www.shooltz.com
For really tiny wait intervals such as a few ms, there are no obvious advantages, and Sleep might in fact be a better solution than creating a kernel object. However, for longer intervals the thread would remain locked until the timeout value expires, which would cause the application to look as if it was hung (and you don't want to use the dangerous TerminateThread API, since it doesn't allow for object cleanup among other unwanted side effects). In this case, it's always better to implement a solution such as the one I suggested.
-
For really tiny wait intervals such as a few ms, there are no obvious advantages, and Sleep might in fact be a better solution than creating a kernel object. However, for longer intervals the thread would remain locked until the timeout value expires, which would cause the application to look as if it was hung (and you don't want to use the dangerous TerminateThread API, since it doesn't allow for object cleanup among other unwanted side effects). In this case, it's always better to implement a solution such as the one I suggested.
Carl Berg wrote: In this case, it's always better to implement a solution such as the one I suggested. With WaitForMultipleObjects? Tomasz Sowinski -- http://www.shooltz.com
-
Carl Berg wrote: In this case, it's always better to implement a solution such as the one I suggested. With WaitForMultipleObjects? Tomasz Sowinski -- http://www.shooltz.com
Yes, exactly, one will have to use WaitForMultipleObjects in order to be able to wait on both the timer and a quit/exitthread event (and possibly other objects as well, depending on design). If the update processing is a lengthy operation, it might be a good thing to check if the quit event has been set at a few checkpoints. This can be done using WaitForSingleObject with a zero timeout value: WaitForSingleObject(hQuitEvent, 0). If the event is set, the return value will be WAIT_OBJECT_0 (cancel update and exit thread), else it will be WAIT_TIMEOUT (continue the update process).
-
Yes, exactly, one will have to use WaitForMultipleObjects in order to be able to wait on both the timer and a quit/exitthread event (and possibly other objects as well, depending on design). If the update processing is a lengthy operation, it might be a good thing to check if the quit event has been set at a few checkpoints. This can be done using WaitForSingleObject with a zero timeout value: WaitForSingleObject(hQuitEvent, 0). If the event is set, the return value will be WAIT_OBJECT_0 (cancel update and exit thread), else it will be WAIT_TIMEOUT (continue the update process).
Hello, INTRODUCTION: First of all let me thank you very much for your help. I think that using a thread in order to read and another one in order to write (with different priorities) will be a great solution for me. As I had written down in the Subject of my first message I'm very novice, but I've bought a Jeffrey Richter book that talks widely about threads and I think that, with this book, I will learn how to manage and use correctly threads. But I have a doubt: QUESTION: OK, I will have a thread that will get all the needed data from the XProgram, and I'll have another thread that will write data to that program too (I think that I'll need some kind of "transfer stack" that I'll will have to modify from outside the threads in order to make them work (one for each thread)...) but, now that it seems that I will simplify the fact of getting and setting data to the XProgram, I would like to know how to send that data to the place where it have to go. Let me explain better: >> I'll have a transfer stack for reading from the XProgram. >> This transfer stack will contain all the variables that I have to read from the XProgram. >> I will use some kind of filters that will avoid reading groups of variables that I don't need by the moment. >> I will know wich group of variables have suffered a change in the XProgram. >> I want to send all the variable groups (those in which some var. have changed) to the dialog that use that information. ----------------------------------------------------------------------------- Which would be the best solution? ID: 01 DESCRIPTION: Sending messages to the main application window passing the first parameter as a mask of the variables group that has been modified in order to be able to call the right update function (in other dialogs that I'll need acces to (ths is not a problem from the main window)). COMMENT: Wouldn't be a slow method due to the messages queue? ID: 02 DESCRIPTION: Calling an updateGUI function in each dialog that need it. COMMENT: Does is this possible? and moreover I will need access to all those functions in all the dialogs... ID: 03 DESCRIPTION: having the same timers that allow me to update the GUI?. COMMENT: why do I use the two threads then? ----------------------------------------------------------------------------- Of course I have not still readed all about threads that is in that Jeff. Richter book, but could you give me an advice about this? Thank you again, and let me promise you