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

[Con Kolivas]

Jeremy White wrote:
> Fyi,
> 
> I spent a great deal of time this past fall exploring Wine scheduling
> issues, and I thought I would post what I learned.
> 
> The most critical point is Wine was pretty badly broken;
> it simply had a number of flaws in how scheduling was done.
> 
> First, the winmm timer, used by a lot of programs,
> was pretty awful.  That has now been fixed, and I believe
> that it now works correctly.
> 
> Second, we did not synchronize Wine message times with X11
> message times properly.  Fixing that resolved some issues
> with Photoshop (and given that Ove reworked that patch into
> WineX the same day I submitted it, I'd guess it fixed some
> games too <grin>).
> 
> Third, Wine did not yield the processor properly at points
> where Windows does, including Sleep(0) and certain event
> conditions.  That's now been (mostly) fixed, I think.
> 
> Fourth, the Wine server had an issue with the way it managed
> it request queues.  To be honest, I don't understand this
> bug or the fix; all I know is that Mike McCormack figured
> this one out and posted a magic fix.  This was, I believe,
> the primary reason that the wineserver would chew 100% cpu
> with iTunes.
> 
> Beyond that, there are a number of ways that Wine
> 'gets lucky' and Just Works (TM) works on the Linux scheduler,
> in ways that we couldn't have asked for.
> 
> First, because many Wine calls resolve into a wineserver
> call, and a wineserver call involves a write to a pipe,
> we potentially risk yielding the processor far more often
> in Wine that a Windows program would 'naturally' do so
> on Windows; opening us to horrendous timing bugs.
> However, in practice, because the Wine server often
> handles requests within a single quanta, and because waiting
> on a pipe with data gets a priority boost in Linux,
> the net effect is what Wine wants.  (Thread A makes a request,
> yields to the Wine server who gets in ahead of all other threads,
> does the requests, sends the response back, and Thread A regains
> control before any other Wine thread because it got a priority boost).

An excellent investigation and summary, thanks! The situation was worse 
than I anticipated. Thankfully it looks like you're not track.

> Second, the new 2.6  average time quanta of 100 ms is comparable
> to the observed Windows quanta of 115 ms (I may have that wrong,
> but I recall they were quite close), although the old, much
> smaller time quanta masked a number of Wine scheduling problems.
> But, in theory, having this longer time quanta should let us
> better replicate Windows scheduling behavior.

Actually this wont help you. The more frequent round robinning of tasks 
with shorter timeslices blurs any priority differences. With longer 
timeslices all you'll get is "resonance"

> However, we still have some issues.  First, the problem with
> thread priorities still remains an issue.  A non zero number
> of important applications rely on Windows priorities to
> change timing behavior to make their applications run properly.
> ([editors note:  imho, these are poorly written apps, but
> we have to support them as they are; wishing that MS would
> rewrite PowerPoint to my spec is amongst the most futile things I can
> imagine]).
> 
> There is a patch Mike worked up which makes a theoretical
> improvement to the Wine server (pull requests from its queue
> in thread priority order), but we have no evidence that
> change makes any difference, and Mike backed away from it
> when he found the afore mentioned 'correct' fix.
> Nonetheless, I think it is conceptually 'right', so we probably
> should bug Mike into redoing that patch.
> 
> I've played with a number of artificial ways to try to replicate
> this within Wine, and have come up with a few compromises, but
> nothing works perfectly (or, more importantly, worked up
> nothing that Alexandre would apply <grin>).  If you do try to exactly 
> mirror
> Windows priorities, for example (running as root, say), you run
> into issues where the wineserver gets starved and Wine stops
> functioning.
> 
> Candidly, that's where I'm stuck.  I'm going to revisit a few
> of my 'problem' apps hopefully sometime this year and see if I can
> cobble together a hack that works best.  Ove, I haven't
> tried the signalling approach; that seems like an interesting idea.
> 
> Sadly, short of asking the Linux guys to rewrite the Linux kernel
> scheduler to exactly mimic Windows behavior, I'm not really
> sure if there is a lot we can do to get this exactly right.

Well the scheduler is not going to be rewritten any time soon (trust me, 
I've tried :P). Tell me what remaining requirements your threads have 
that you are unable to achieve at the moment and I'll see if I can help 
with my understanding of the priority system as it is, in a generic way 
that hopefully will work across scheduler designs.

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/19160911/signature.pgp