Hello Mr No,
In my point of view, there is always a solution,
only few thread needs such high resolution timing,
for example limiting the number of Client RT Thread can be a way
Well, the suggestion is done, let the time going on
and brains sleeping on
maybe a year or two
Regards
Vincent Burel
De : wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Tim Roberts
Envoyé : jeudi 29 septembre 2016 19:51
À : wdmaudiodev@xxxxxxxxxxxxx
Objet : [wdmaudiodev] Re: Windows & Real Time : suggestion to Microsoft
Kernel Developers
Vincent Burel (VB-Audio) wrote:
Well, Details of implementation is another story... and is for Kernel
Developers
uSleep() function could be applicable with specific Thread only
maybe a
CreateThreadRT function could be created
Or a RegisterRTTimer with callback could be another solution
Yes, but a kernel developer has to consider what happens if there are 20
client threads who all want that treatment. You can't dedicate one hardware
timer to each thread. You have to have a general case solution. That
necessarily implies short scheduler intervals, and that increases overhead.
Each timer expiration means an interrupt, a scheduler evaluation, and a
context switch.
Seriously, if there were an obvious solution, it would have been done years
ago. This is why Windows has never attempted to advertise real-time
capabilities.
But the essential point to understand is the flexibility (opposite to a
strict callback):
You decide in your loop when you wait a cycle (of 10ms, 1ms or 0.1 ms)
whatever the duration of your processing is
Because even for big latency processing, the smaller time granularity you
have, the smaller Jitter you get.
Yes, but that smaller jitter comes at a performance cost, and very few
developers have the discipline to do a cost/benefit analysis with
system-wide implications.
--
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.
