[ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]

[Con Kolivas]

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 
> Wine.
> 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 
first place.

> 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>

Exactly.

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.

Cheers,
Con
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20050114/a0885856/signature.pgp