|
I DID do it so, as I wrote it in the original post (my addition, that this did not correct the error was wrong).
My main point was and is, that this contradicts the MS VC++ 6.0 documentation.
|
|
|
|
|
So what's the point of your post then? If you need help with a problem, a solution has been provided. If you're just wanting to rant about MS's documentation, take a number. It's a known fact that you can't rely 100% upon MSDN documentation. While errors are rare, they do occur and thus you should be prepared to make corrections.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
The docu of VC++6.0 is miserable, but that's not the same as factually erroneous. I haven't got used to the idea of fighting against factual errors in the documentation.
However, in fairness I have to say, that this is not an error in the docu. After re-reading the documentation, I realized it: it states only that the definition does not have to be prior the pointer, but it says nothing about the declaration.
|
|
|
|
|
To add to Joe, This proves, its always better to provide problem code snippet.
|
|
|
|
|
I am using Sleep(10) in my thread to post a windows message every 10ms.
In the function responding to the windows message, I find that it is being executed approximately every 16ms. Where does the 6ms delay come from? My computer is not the best 1.53GHz, but 6ms delay is still way too slow.
|
|
|
|
|
Posting a message puts it in a queue; the speed at which the messages are removed from the queue by the receiving thread need not be directly related to the rate at which they're posted. For example, factors such as the time taken to process the message and thread scheduling come into play.
Steve
|
|
|
|
|
Is there a way to accurately predict the actual time it takes to post a message? The function I'm using is depended on that time.
Is there another way I can force the function to execute at specified time intervals, and accurately? Is there something like time() that would return ms instead of seconds?
|
|
|
|
|
acerunner316 wrote: Is there a way to accurately predict the actual time it takes to post a message?
It doesn't take long to post a message as it's simply queued. The delay comes into play because of the contents of the queue, the speed at which the receiving thread calls GetMessage and processes the message and thread scheduling.
acerunner316 wrote: Is there another way I can force the function to execute at specified time intervals, and accurately?
Probably the most accurate way would be to use a dedicated high priority thread which calls the function directly then sleeps, in a loop. Naturally if the approach is feasible or not in your case depends on what your function does.
acerunner316 wrote: there something like time()
Check out GetTickCount.
Steve
|
|
|
|
|
Stephen Hewitt wrote: Probably the most accurate way would be to use a dedicated high priority thread which calls the function directly then sleeps, in a loop. Naturally if the approach is feasible or not in your case depends on what your function does.
The reason I am posting a message and not directly calling the function is because the function references members of the main class, and I remember reading somewhere that you can't do that in a thread. So how can I create a dedicated thread that calls the function directly.
Thanks.
|
|
|
|
|
That's not an easy question to answer without detailed knowledge about what you're trying to do and how you've gone about doing it.
Steve
|
|
|
|
|
Basically, my program is sampling data from an external USB device. The data is displayed in the window as well as logged to a file. I want to sample and log the data at a specified sampling rate. In this case, I chose every 10ms. The retrieval in done through API calls in the function that's responding to the windows message posted by the thread. My logic was that if I post the message every 10ms, the function will run every 10ms and therefore sampling rate will be 10ms. Clearly, this is not the case.
Hopefully that clears things up.
|
|
|
|
|
There are a number of approaches I'd consider:
The first is to abandon the idea of having “super accurate” callbacks. Instead just use a reasonably accurate mechanism, such as SetTimer or your current scheme, but record the time of each sample along with the sample data.
The second would be to use a high priority thread like I described earlier to do all the sampling and fill buffers which can be accessed by the UI thread – with appropriate synchronization.
On a side note be aware that posting messages from another thread is probably only marginally more accurate then using SetTimer.
Steve
|
|
|
|
|
well, it doesn't have to be super accurate, but 6ms delay out of the specified 10ms is huge. 1 or 2 ms might be acceptable.
Can you explain how I would use SetTimer to solve my problem, where would I call it?
Also can you explain how to use a high priority thread. Would I be able to access member variables/functions of the main class? Does it operate differently than a worker thread.
|
|
|
|
|
acerunner316 wrote: Can you explain how I would use SetTimer to solve my problem, where would I call it?
Calling SetTimer wouldn't solve your problem. I was just pointing out that using SetTimer instead of posting messages from a worker thread would be simpler and only marginally less accurate.
acerunner316 wrote: Also can you explain how to use a high priority thread. Would I be able to access member variables/functions of the main class? Does it operate differently than a worker thread.
When I said a "high priority" thread I simply meant a worker thread with a high priority. A thread's priority can be set using SetThreadPriority. Normally having a thread with a really high priority is a bad idea but since our thread spends most or its life asleep and when it is awake just takes a sample then goes back to sleep it’s ok. In this context the high priority is just to reduce the scheduling overhead so that our thread is chosen by the scheduler earlier than others when the sleep time has expired. As to accessing member variables of a class that’s a complex question which would require more detailed knowledge of your application.
Steve
|
|
|
|
|
acerunner316 wrote: Is there a way to accurately predict the actual time it takes to post a message?
no. and your process could get preempted at any time.
acerunner316 wrote: Is there another way I can force the function to execute at specified time intervals, and accurately?
not really. WM_TIMER isn't very accurate (or reliable).
acerunner316 wrote: Is there something like time() that would return ms instead of seconds?
QueryPerformanceCounter[^] might help with that.
|
|
|
|
|
Chris Losinger wrote: QueryPerformanceCounter[^] might help with that.
I think that's shooting a bit over the top. GetTickCount() is probably just about right for what he's trying to time.
--
Not based on the Novel by James Fenimore Cooper
|
|
|
|
|
he was talking about accuracy in the 10-20ms range. GetTickCount can't get near that.
|
|
|
|
|
So.. uh, the system timer resolution is too low? Lucky me that I don't have to do anything multimedia related, because I was under the impression that a timer which is given the attribute system would be the most accurate one. Thanks for the heads up - who knows? I might have to deal with issues like this some day...
--
Verletzen zerfetzen zersetzen zerstören
Doch es darf nicht mir gehören
Ich muss zerstören
|
|
|
|
|
it's updated every ~15ms to 50ms (depending on the version of Windows). so, it is measuring time in the ms range, but the difference between two consecutive calls will never be less than ~15ms.
QueryPerformanceCounter is much more accurate.
|
|
|
|
|
How will I use QueryPerformanceCounter as a way of sampling data? I will still need a thread to loop a function call. And in that function will check QueryPerformanceCounter. But if posting a message takes longer than 6ms. Then QueryPerformanceCounter can only be as accurate as that.
Can you provide a code sample? Im fairly new to windows programming. I am basically learning from sample code that I find online. Thanks.
|
|
|
|
|
acerunner316 wrote: I will still need a thread to loop a function call. And in that function will check QueryPerformanceCounter.
right
acerunner316 wrote: But if posting a message takes longer than 6ms. Then QueryPerformanceCounter can only be as accurate as that.
right
maybe this article can help... scroll down to the bottom for a message-loop / QueryPerfCounter sample.
|
|
|
|
|
sorry, i'm still having trouble understanding. In code sample at the link you gave, I can see that the function is monitoring for any messages and checking for the time. But there is the message being generated from, and how?
|
|
|
|
|
acerunner316 wrote: But there is the message being generated from, and how?
the message comes from code outside the loop. this is pretty close to an old-style C Windows message loop. Windows is passing messages (button down, repaint, keydown, etc) to the application, which the app grabs, when it sees one, and starts processing with that Peek/Translate/DispathMessage bit - other code is responsible for handling the specific msgs. otherwise, every 40ms, the app does a run through its Render/Move/etc stuff, then goes back to looking for messages.
|
|
|
|
|
Isn't this similar to what I'm already doing, posting messages every 10ms? Because what I'm doing is posting the message repeatedly in a loop every 10ms. And then I have a function mapped to handle that message ON_MESSAGE(WM_UPDATE_DATA, OnUpdateData). So the only difference I see is instead of using ON_MESSAGE, I will have my own function that loops to check for the message posted an respond to it. Is this right? Will this make the difference of the 6ms delay? Would I have to post this message like every 1ms in order to get the 1ms resolution?
|
|
|
|
|
acerunner316 wrote: Isn't this similar to what I'm already doing, posting messages every 10ms?
pretty much. but Sleep simply isn't that accurate. Sleep uses the system clock, which has a resolution closer to 15ms per tick in most modern versions of Windows. and, it's entirely possible for your sleeping thread to get preempted by another thread, further delaying its awakening.
i'm not sure what the overhead in PostMessage / ON_MESSAGE amounts to. but they're asynchronous anyway; apps respond to messages when they get around to it, not the instant they appear in their message. the time from PostMessage to the actual response is (i believe) indeterminate.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
