SetEvent and WaitForSiongleObject
-
Albert Holguin wrote:
You're the one that needs help
No I don't. Just pointing out the crap that is Microsoft.
Then why are you posting this to Q&A? I can tell you that signaling isn't slow, you have something wrong with your code... but you somehow refuse to listen. I suggest you set up a test scenario and figure out what's wrong with your code before blaming something that's been around and widely used for years.
-
Then why are you posting this to Q&A? I can tell you that signaling isn't slow, you have something wrong with your code... but you somehow refuse to listen. I suggest you set up a test scenario and figure out what's wrong with your code before blaming something that's been around and widely used for years.
Dot you think that well inside 4 to 8 seconds the thread with the read file should get de-scheduled and the one with the write file scheduled within a reasonable time of the wait being satisfied? Clearly it isn't. That's the problem. I shouldn't have to put the read file thread to sleep, it should be descheduled automatically.
-
You have seen the code I supplied, it really is as simple as it looks: There are two write files, in two different threads. Both are synchronous write files. When the first write file completes it and sets an event and goes into a read cycle. The second write file is in a thread waiting for the event to get signalled. The time between the two write files is often many seconds. What is happening during that time is a setevent and a wait being satisfied.
Where the system spend the delay time: before or after the WaitForSingleObject or SetEvent? Looking to the data over USB from external analyzer doesn't tell you. How can you be so sure that the delay come from the thread synch if you don't know when it gets out of it? This is what people here are asking you.
-
Where the system spend the delay time: before or after the WaitForSingleObject or SetEvent? Looking to the data over USB from external analyzer doesn't tell you. How can you be so sure that the delay come from the thread synch if you don't know when it gets out of it? This is what people here are asking you.
I don't know, I only have the external events; the two write files, to go by.
Frankie-C wrote:
How can you be so sure that the delay come from the thread synch if you don't know when it gets out of it
Why would a thread schedule, look at a while statement, and then either stall before the write file, or somewhere inside it? You cant honestly suggest the thread timeslice is in the order of seconds; the thread doing the read file should be descheduled and the recently waiting thread should be run far quicker than that.
-
I don't know, I only have the external events; the two write files, to go by.
Frankie-C wrote:
How can you be so sure that the delay come from the thread synch if you don't know when it gets out of it
Why would a thread schedule, look at a while statement, and then either stall before the write file, or somewhere inside it? You cant honestly suggest the thread timeslice is in the order of seconds; the thread doing the read file should be descheduled and the recently waiting thread should be run far quicker than that.
I've been not very clear. I didn't meant the thread scheduling, but the WaitForSingleObject. I'll try to clarify my question: are you sure that your code is in the WaitForSingleObject waiting for the event, and when the event is set the code take a walk around and after some time remember that it was waiting for something and proceed? Or maybe the execution is wasted in different instructions (i.e. the file read or write that are in your code) while the event is set, then getting out few seconds later executes the WaitForSingleObject find the event set and jumps out immediatley (as is exepected from WaitForSingleObject), bat late anytime? The point is that the wait for objects is the base of synch for all software in windows, should it behave as you say nothing should work. That is the reason why we believe that the source of delay should be somewhere else (driver delays, timeouts or else). Then for the quality of MS code there is a lot of space for discussions... :laugh:
-
I've been not very clear. I didn't meant the thread scheduling, but the WaitForSingleObject. I'll try to clarify my question: are you sure that your code is in the WaitForSingleObject waiting for the event, and when the event is set the code take a walk around and after some time remember that it was waiting for something and proceed? Or maybe the execution is wasted in different instructions (i.e. the file read or write that are in your code) while the event is set, then getting out few seconds later executes the WaitForSingleObject find the event set and jumps out immediatley (as is exepected from WaitForSingleObject), bat late anytime? The point is that the wait for objects is the base of synch for all software in windows, should it behave as you say nothing should work. That is the reason why we believe that the source of delay should be somewhere else (driver delays, timeouts or else). Then for the quality of MS code there is a lot of space for discussions... :laugh:
I understood, lets go back to the code: As you say is the write thread getting stuck in the wait, or in the write. The thing is, in either case, since both threads are of equal priority, the read thread Write thread:
while(pDlg->Go) { WriteFile(gh, buf, towrite, &written, 0); WaitForSingleObject(pDlg->WriteTrigger, INFINITE); }Read thread:
while(pDlg->Go) { ReadFile(gh, buf, 1024 - readTot, &read, 0); ... process data, snipped WriteFile(gh, &ACK, 1, &written, 0); SetEvent(pDlg->WriteTrigger); }should get descheduled and the write thread scheduled in an even way, they should both get CPU time equally. What looks to be happening is that the read thread is having a lot of CPU time (its a multi core CPU) and blocking the handle at an IO level thus stalling the write. What I find really surprising is that the read thread can run for up to 8 seconds. The solution would be for the read thread to wait on the event immediately after it sets it, and then for the write thread to set it and wait immediately: Write thread:
while(pDlg->Go) { WriteFile(gh, buf, towrite, &written, 0); SetEvent(pDlg->WriteTrigger); WaitForSingleObject(pDlg->WriteTrigger, INFINITE); }Read thread:
while(pDlg->Go) { ReadFile(gh, buf, 1024 - readTot, &read, 0); ... process data, snipped WriteFile(gh, &ACK, 1, &written, 0); SetEvent(pDlg->WriteTrigger); WaitForSingleObject(pDlg->WriteTrigger, INFINITE); }But that is an ugly piece of code to look at! :)
-
I understood, lets go back to the code: As you say is the write thread getting stuck in the wait, or in the write. The thing is, in either case, since both threads are of equal priority, the read thread Write thread:
while(pDlg->Go) { WriteFile(gh, buf, towrite, &written, 0); WaitForSingleObject(pDlg->WriteTrigger, INFINITE); }Read thread:
while(pDlg->Go) { ReadFile(gh, buf, 1024 - readTot, &read, 0); ... process data, snipped WriteFile(gh, &ACK, 1, &written, 0); SetEvent(pDlg->WriteTrigger); }should get descheduled and the write thread scheduled in an even way, they should both get CPU time equally. What looks to be happening is that the read thread is having a lot of CPU time (its a multi core CPU) and blocking the handle at an IO level thus stalling the write. What I find really surprising is that the read thread can run for up to 8 seconds. The solution would be for the read thread to wait on the event immediately after it sets it, and then for the write thread to set it and wait immediately: Write thread:
while(pDlg->Go) { WriteFile(gh, buf, towrite, &written, 0); SetEvent(pDlg->WriteTrigger); WaitForSingleObject(pDlg->WriteTrigger, INFINITE); }Read thread:
while(pDlg->Go) { ReadFile(gh, buf, 1024 - readTot, &read, 0); ... process data, snipped WriteFile(gh, &ACK, 1, &written, 0); SetEvent(pDlg->WriteTrigger); WaitForSingleObject(pDlg->WriteTrigger, INFINITE); }But that is an ugly piece of code to look at! :)
-
Yes ugly indeed, you could consider using Sleep() with a very short timeout to suspend current thread of execution. This should fix back the synchronization.
Sleeps arent performance optimal though, and this test app is designed to hammer some hardware hard for a day or so, so I need it to run as quick as it can. Anyway, I put the second write into the same thread as the read and its running OK now of course.
-
Sleeps arent performance optimal though, and this test app is designed to hammer some hardware hard for a day or so, so I need it to run as quick as it can. Anyway, I put the second write into the same thread as the read and its running OK now of course.
-
I see, my suggestion was to put a minimal delay of 1ms to use the side effetct of suspending thread execution. Anyway the solution to avoid handle concurrency is the fastest per sure.
Yeah, triggering a small sleep might be enough to get the thread off the CPU for long enough.