[ck] Re: Threading issues? [email@example.com: ck Digest,
Vol 3, Issue 16]
kernel at kolivas.org
Thu Jan 13 22:44:31 CST 2005
Jeremy White wrote:
> Specifically, there are other areas of interest when you think about
> timing and scheduling. First is the Windows very clear cut 'foreground
> window' boost. I have no idea how this maps into the Linux
> interactivity strategy. They seem to be roughly equivalent, and I
> never found an application that relied on that timing.
We do nothing of the sort. There is no special casing in the kernel for
any processes that aren't kernel threads. However, the more frequently a
task sleeps, the more priority it is rewarded with. That tends to select
out interactive tasks.
> That connects to the theoretical flaw in Wine (the whole use of the
> Wine server) that should make us vulnerable to all sorts of
> unexpected context switches, creating timing patterns unfamiliar
> to Windows applications, and causing problems. And yet,
> from observation, I never see any such unexpected context switches.
> The Linux kernel priority boost for pipes seems to protect us here;
> we should make sure we understand why and let the kernel guys know that
> we depend on it, so they don't knock it out from under us some day.
No chance again. The reason you get priority boost on pipes is a task is
waiting, therefore it is sleeping.
> Fourth, based on your reply to my earlier email, I suspect I do
> not understand how time quanta are assigned. In fact, I had come to
> some conclusions at one point last fall, that I can no longer
> convince myself of (I was persuaded that a thread that constantly
> yielded had it's time quanta dranstically reduced; I can no longer
> reproduce that). Further, time quanta differences can be crippling to
> Photoshop, for example, relies on reliable 5ms timing, and if it doesn't
> get it, it doesn't work. Similarly, I could swear I had a problem
That can't be true. What you are saying is it needs at least 5ms
timeslice on hardware that is equal to or faster than the machine you
tested it on. We cannot guarantee any timeslice of any size will occur
uninterrupted in the linux kernel. For tasks that are not nice'd, the
usual minimum slice is 10ms. But if something higher priority than it
wakes up in the interim, it will be preempted even if it is 50
microseconds into its timeslice.
> case in IE where two threads were interdependent, and the one thread
> never got a large enough quanta to keep the second thread happy (and
> this then caused a spiral that led to the small quanta for thread A).
This is not at all unusual. If there is no locking between threads, and
you simply hope that one will complete in time for the other, you will
get various degrees of priority inversion. Native linux applications do
it too, and 2.6 has forced them to improve their coding principles (see
the thread on 'blender' in the linux kernel mailing list during 2.5
development. There are various algorithms that have been tried to detect
when this is happening and inherit appropriate priorities, but they have
their own overhead and aren't as effective as proper blocking in the
> Sadly, I didn't take good notes, so I have to go back and relearn that case
> again. And, knowing me, I probably completely misunderstood it anyways
Not really. It sounds very much like you've got the thrust of the
problem to me :)
> Sorry to ramble on; it's just tough around here, because everyone
> is tired of hearing me claim that every bug is a timing problem... <grin>
Generous use of blocking where appropriate is the answer to being
friendly to any scheduler. Hoping dependant threads will complete in
time is futile as the speed of execution of each thread will change on
different schedulers, hardware etc.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20050114/a0885856/signature.pgp
More information about the wine-devel