RE: [GD-Windows] TryEnterCriticalSection

[Jon W. <hp...@mi...>]

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
>