Original post by lucky_monkeyQuote:The thing is that Winamp uses multiple threads (5 right now on my comp -- going to 9 when I start to play music) all of which get their own time quantum. Only the threads that try to use 16-bit components are going to block. I don't know if playing sound requires 16-bit stuff though, so you could be right about the lock being your problem.
Original post by MaulingMonkey
Glad to have this cleared up, although it changes next to nothing :). If winamp is blocking due to a UI call relying on a win16mutex (not unlikely given how graphical winamp is), then you'll still get the effect of timeslices getting "added up" (in the context of "winamp starving")
I'm too lazy to explicitly test this, but considering winamp often stops playing when my DirectX based games crash (even when the system manages to recover), I'm guessing that indeed, it's locking.
Quote:Fair enough [smile]
Original post by MaulingMonkey
Not really. You're talking to a guy who used Zenix, and worked quite often in the recent past (1 year) with plenty of ancient OSes not mentioned in that blurb. Just because they're ancient dosn't mean they don't exist, and are unworthy of (historial) mention :).
I don't really like the idea of explicitly yeilding threads (e.g. sleep(0)), but I suppose that it can be useful for some things. [smile]
My most recent odd OS experience was with SCO OpenServer 5.5, being used in a toystore to host the point of sales software they've been using. Personally, I would've liked to have switched the store over to some open source software, as the stuff they were using was hideously expensive, and the more advanced features were unusable due to bugs anyways. Not to mention the entire company (providing the software) has downsized to two employees, meaning technical support is at a minimum, and what upgrades do become available are still buggy.
Unfortunately it wasn't my decision to make. They may switch over to Solaris, as that's the more supported of the two systesm that this software is designed for, and is reportedly more complete and stable.
But back to topic:
Admittedly, sleep(0) in and of itself is rather crude, although for lower tier games it should do the job just fine. For those pushing the envelop of gamer technology, one can expand on this, by attempting to glean more detailed information about how much of a timeslice is left, and only explicitly yeilding when the timeslice is nearly done, or switching to non locking tasks. A micro-management of thread timing if you will. Example:
If you have 1 second timeslices (to continue on the absurd example) when you know you have 10ms left only, then some options would be only then explicitly sleeping (thus wasting little of your timeslice) between your locks if executing rendering code, or prehaps switching to processing AI, something that's not going to lock those resources, allowing full utilization of the timeslice given.
This is getting into a rather messy area of optimization however, and it removes the linearity of game loop logic. The rendering code would need points of checking/potential entry spots to switch over to AI/game logic/whatever, and need to be able to continue rendering the scene after that code has been executed, without any difference. This can lead to double-buffering of game data (to match the screen buffering) and other potentially high costs, which may outweigh the benifits.