RE: [GD-Windows] TryEnterCriticalSection

[Brian S. <bs...@mi...>]

I'm not sure that "snooze and re-try" is much better than calling a wait
function (EnterCriticalSection, WaitForxxxx, etc.) that triggers a
context switch, for a few reasons.  If you're just going to spin and
wait, then you've got a thread doing nothing while other threads could
be working.  If you call Sleep, you give up the rest of your timeslice
and trigger a context switch anyway.  The scheduler can trigger context
switches at any time - it doesn't need to wait for you to call Sleep -
so it's not like you can prevent that, unless you stop using threads and
switch to a polling model.  Finally, if the network thread is using a
wait function on a socket to block until data arrives, it won't even be
considered for scheduling, so that improves your chances of not entering
a race with the main thread. =20

It seems to me that the best approach is use OS locks and minimize the
time locks are held.  Am I missing something here?

--brian

-----Original Message-----
From: Jon Watte [mailto:hp...@mi...]=20
Sent: Thursday, January 03, 2002 4:15 PM
To: Gamedevlists-Windows@Lists. Sourceforge. Net
Subject: RE: [GD-Windows] TryEnterCriticalSection


In my experience, when you find you want to "try to grab a lock if=20
possible," you are most often better off re-designing your algorithm=20
to not use that. More often than not, there's a race waiting to happen=20
that you don't realize if you find you need this.

And, for low-latency applications (like games), I've found that you're=20
much better off using non-blocking primitives than trying to go through=20
context switches -- they add up pretty quickly! A non-blocking* FIFO is=20
quite simple to implement using an atomic add-and-return-old-value=20
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=20
events waiting to be inserted implemented as a non-blocking FIFO, and=20
have the "poll for next event" function empty out whatever's there when=20
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"=20
operation fails because there's not enough space, though -- snooze and=20
re-try is often good enough; the idea is that you allocate a sufficient=20
buffer area up-front that you seldom get into that case, and when you=20
do, snoozing is the right thing to do because the other guy's falling=20
behind too much. If you're using a non-reliable mechanism like UDP, you=20
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
>=20
>=20
> It looks like TryEnterCriticalSection is only available on >=3D 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).
>=20
> Any opinions, comments or shared experiences with this?
>=20
> Brian
>=20
>=20
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>=20

_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows