In my experience, when you find you want to "try to grab a lock if
possible," you are most often better off re-designing your algorithm
to not use that. More often than not, there's a race waiting to happen
that you don't realize if you find you need this.
And, for low-latency applications (like games), I've found that you're
much better off using non-blocking primitives than trying to go through
context switches -- they add up pretty quickly! A non-blocking* FIFO is
quite simple to implement using an atomic add-and-return-old-value
function, if you only ever have one reader and one writer, for example.
For your event queue, you could just have a sufficiently large list of
events waiting to be inserted implemented as a non-blocking FIFO, and
have the "poll for next event" function empty out whatever's there when
the function gets entered and put it into the queue.
Cheers,
/ h+
* Non-blocking primitives force you to decide what to do if the "put"
operation fails because there's not enough space, though -- snooze and
re-try is often good enough; the idea is that you allocate a sufficient
buffer area up-front that you seldom get into that case, and when you
do, snoozing is the right thing to do because the other guy's falling
behind too much. If you're using a non-reliable mechanism like UDP, you
may decide to start dropping packets instead.
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Hook
> Sent: Thursday, January 03, 2002 11:18 AM
> To: gam...@li...
> Subject: [GD-Windows] TryEnterCriticalSection
>
>
> It looks like TryEnterCriticalSection is only available on >= NT4 (and
> according to the docs, it's not available on Win9x at all). To get
> around this I'm thinking that I could switch to using a mutex and
> WaitForSingleObject with a timeout of 0 milliseconds, but mutexes are
> heavier weight than critical sections (I'm not sure how bad this is in
> practice though).
>
> Any opinions, comments or shared experiences with this?
>
> Brian
>
>
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>
|
