|
Thakur JAI SINGH wrote:
But it is not working for me.
What specifically is not working? You have 5 statements here. Have you stepped through each one using the debugger to see which one is not working as expected?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
So I have a thread, thread one, that writes a byte (an ACK) to a COM port (COM over USB), then sets an event, and a thread, thread two, that's waiting on that event with WaitForSingleObject, INFINITE, which then writes 7 bytes to the port, then goes back to waiting again. Thread one, then reads data from the port, and when its got the whole chunk, writes the ACK, sets the event, and so it goes round again. ad infinitum.
Now I have a USB analyser on the wire, so I can see the timing here, between the one byte ACK going out, and the 7 bytes of data, and it is sometimes 4 seconds!  
4 seconds? One thread does a SetEvent, and the other thread, doing a WaitForSingleObject takes 4 seconds to get notified?
Dont believe me?
613 . 0x06 8 2/23/2015 5:52:20.593552 PM
614 .ABCD.. 0x02 58 56 45 52 03 1a 14 2/23/2015 5:52:24.094321 PM
See, almost 4 seconds, that's the USB sniffer trace. What the hells going on?
Just seen one trace go by, and its 8 seconds!
I mean, cant MSFT tighten it up a bit? This is appaling!
( By the way, the driver is mine, and the time between the IRP_MJ_WRITES of 1 byte, and 7 bytes, also reflects the large gaps seen on the USB bus. The driver traces when its hit by the app calling WriteFile() so its not a problem in the driver either, it really is the thread scheduling. )
|
|
|
|
|
If this were true, there would be A LOT of very slow programs out there.... you likely have some other bug in the code. Signaling should be pretty fast.
You'll need to post some source if you want any help though...
|
|
|
|
|
Event created thus:
WriteTrigger = CreateEvent(NULL, FALSE, FALSE, "arse");
This is the write thread (yeah, its MFC):
AFX_MANAGE_STATE(AfxGetStaticModuleState());
while(pDlg->Go)
{
if(!WriteFile(gh, buf, towrite, &written, 0))
{
pDlg->doerror();
}
WaitForSingleObject(pDlg->WriteTrigger, INFINITE);
}
Here is the read thread:
AFX_MANAGE_STATE(AfxGetStaticModuleState());
while(pDlg->Go)
{
ReadFile(gh, buf, 1024 - readTot, &read, 0);
... process data, snipped
WriteFile(gh, &ACK, 1, &written, 0);
SetEvent(pDlg->WriteTrigger);
}
As you can see, its very very simple and I cant see any reason for the often massive delays. As I said, my driver traces the incoming reads and writes off the app aswell, and it confirms that the delay is in usermode.
Albert Holguin wrote: If this were true, there would be A LOT of very slow programs out there....
Er, ever used Windows 7? 
Seriously though, I have been writing Windows kernel drivers, and using MFC to write test apps, and utilities for that entire time too. I have written all sorts of threaded code in the Kernel, and never seen any delays like this using KeWaitforSingleObject and KeSetEvent.
It just looks like really crap user mode thread scheduling (this is win 7 64, the app is win32).
|
|
|
|
|
It looks like a design error. You use a blocking ReadFile call. It would be better to use overlapping reads or wait for data available. Overall I would use only one thread (which should be a worker thread):
Thread loop:
Write data to trigger receiption
Read data overlapped
When ReadFile returns ERROR_IO_PENDING
Wait for completion
Process data
Write ACK
Optional short wait time (may also check for a thread kill event)
To report errors occuring in the worker thread you can send user defined messages to your main (GUI) thread.
Similar when data processing requires some GUI output or is performed by another thread (then set an event when processing is finished and wait for it at the end of the communication thread).
|
|
|
|
|
No no no no no.
Read what I wrote. The time lag between the writefile in one thread, and the writefile in the other often exceeds 4 seconds, and the only thing happening between them is a setevent and a thread schedule.
By the way overlapped IO is not as quick as direct, and the fact I have threads obviates the need for it anyway.
|
|
|
|
|
You should show all applicable code (CreateEvent, thread initialization, any other code in the threads).
Munchies_Matt wrote: Er, ever used Windows 7?
I've been working with high-speed software for about a decade. In both Windows and Linux.
Munchies_Matt wrote: It just looks like really crap user mode thread scheduling (this is win 7 64, the app is win32).
No, it's not. You have another issue. As was already mentioned, it is likely one of the other blocking calls you're making. You can easily set up a test to see how fast events are triggered and release waits with a timer. You'll find it's not very long.
|
|
|
|
|
Albert Holguin wrote: You should show all applicable code (CreateEvent, thread initialization, any other code in the threads).
I gave you the CreateEvent code, there aren't any other threads (except for the main thread, the event is not waited on or used anywhere else than shown, and the thread initialisation is with the usual CreateThread() call:
trHR = CreateThread(NULL,0, &ThreadReadProc, this, 0, 0);
Albert Holguin wrote: You have another issue. As was already mentioned, it is likely one of the other blocking calls you're making
As I told the other guy, no, this isn't that case. As you can see from the code the read file completes, a write file is done, and an event signalled. The waiting thread only does a write file.
How much more simply can it be explained to you? You have seen the code, and moving the second write file into the same thread as the first write file results in no delay at all demonstrating that the fault lies in the thread scheduling.
I also don't need a timer to tell me anything, I have a USB bus analyser running and tracing from my driver thats telling me its taking over 4 seconds for the waiting thread to get scheduled.
|
|
|
|
|
Munchies_Matt wrote: How much more simply can it be explained to you? You have seen the code, and moving the second write file into the same thread as the first write file results in no delay at all demonstrating that the fault lies in the thread scheduling.
You're the one that needs help, not us. I suggest you listen to suggestions and think about them instead of being negative.
Munchies_Matt wrote: I have a USB bus analyser running and tracing from my driver thats telling me its taking over 4 seconds for the waiting thread to get scheduled
That's telling you there's problems in your code, not that there's problems with the thread handling in Windows.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Oh, and I just put the code into one thread, which removes the wait and set event, and it runs without any delay at all, of course.
modified 24-Feb-15 6:11am.
|
|
|
|
|
Do you have the read and write calls reading/writing from the same place? ...you probably have a thread deadlock most of the time.
|
|
|
|
|
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.
|
|
|
|
|
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... 
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
I am using DeviceIoControl with IOCTL_DISK_GET_DRIVE_LAYOUT_EX to get drive information because I need physical offset of drive.
I am getting wrong result so I did some analyses and found that my all drives are of type 0x42 (Basic Dynamic Drive). It means this control code does not give correct information for Dynamic Drives.
Can you help me to get information about drives?
|
|
|
|
|
I try to implement classical sorting algorithm, I do not understand why my quicksort is slower than my mergesort. I spend a lot of time trying to understand why. Do you have any idea ?
For both :
#define ARRAY_INDEX(tab, i) ((void*)((char*)(tab) + (i) * type_size))
My mergesort :
void merge(void *tab, void *aux, int a, int b)
{
int i, j, k, mid;
ft_copy_tab(tab, aux, a, b);
mid = (a + b) / 2;
i = a;
j = mid + 1;
k = a;
while (k <= b)
{
if (i > mid)
ft_copy_index(tab, aux, k, j++);
else if (j > b)
ft_copy_index(tab, aux, k, i++);
else if (f_cmp(ARRAY_INDEX(aux, i), ARRAY_INDEX(aux, j)) > 0)
ft_copy_index(tab, aux, k, j++);
else
ft_copy_index(tab, aux, k, i++);
k++;
}
return ;
}
My quicksort :
void ft_quicksort(void *tab, int a, int b)
{
int i, lower, upper;
if (a >= b)
return ;
lower = a;
upper = b;
i = a;
while (i <= upper)
{
if (f_cmp(ARRAY_INDEX(tab, lower), ARRAY_INDEX(tab, i)) > 0)
{
ft_swap(tab, lower, i, type_size);
lower++;
i++;
}
else if (f_cmp(ARRAY_INDEX(tab, lower), ARRAY_INDEX(tab, i)) < 0)
{
ft_swap(tab, i, upper, type_size);
upper--;
}
else
++i;
}
ft_sort(tab, a, lower - 1);
ft_sort(tab, upper + 1, b);
}
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
