Thread yeilding the processor

Hi,
Is SDL_Delay(0) a good way to yeild the processor to allow other
threads the chance to execute? I know that in general threading
behaviour is hard to determine, but I am looking to do the equivelant
of sched_yeild().

Would SDL_Delay(1) or SDL_Delay(10) be any better?–
Paul Richards

— Paul Richards <paul.richards at gmail.com> wrote:

Hi,
Is SDL_Delay(0) a good way to yeild the processor to
allow other
threads the chance to execute? I know that in
general threading
behaviour is hard to determine, but I am looking to
do the equivelant
of sched_yeild().

Why aren’t you using sched_yield?>

Would SDL_Delay(1) or SDL_Delay(10) be any better?


Paul Richards


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.

Donny Viszneki wrote:

— Paul Richards <paul.richards at gmail.com> wrote:

Hi,
Is SDL_Delay(0) a good way to yeild the processor to
allow other
threads the chance to execute? I know that in
general threading
behaviour is hard to determine, but I am looking to
do the equivelant
of sched_yeild().

Why aren’t you using sched_yield?

Because sched_yield is for posix systems only, and SDL also works on
non-posix systems ?

Would SDL_Delay(1) or SDL_Delay(10) be any better?

Hah. That’s platform dependent, to be on the safe side ask for a
non-zero value and hope the granularity isn’t too great (there are
plenty of threads about SDL_Delay granularity, for example google for
"Misuse of SDL_Delay?").

There was someone asking on the list some time ago why the behaviour of
SDL_Delay(0) was different under linux and under windows (IIRC windows
yields with SDL_Delay(0), while linux instantly returns). I didn’t
follow the thread closely but you might want to google it to be sure.

Stephane

Because sched_yield is for posix systems only, and
SDL also works on
non-posix systems ?

You know I was answering another email and thinking
about mingw and cygwin, and for some reason my mind
blended that email into this one.__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.

I’d suggest that SDL_Delay(0) should be the normal way to say “yield the
processor, but don’t sleep if nothing else wants to run”. If Linux NOPs
on usleep(0), then add a check in the Linux implementation, eg
"if(ms == 0) sched_yield(); else usleep(ms * 1000);". That’s the only
sensible interpretation of 0 I can think of, anyway.

Using SDL_Delay(1) on some archs isn’t acceptable; it’s likely to give a
10ms sleep in Linux 2.4, and I think it caused similar problems on OSX.

Fundamentally, whether or not you need to yield CPU this way is platform-
dependent. I need to in Windows, or my other threads tend to starve. I
can’t in Linux and OSX, or it sleeps too much.On Tue, Jun 15, 2004 at 12:39:47AM +0200, Stephane Marchesin wrote:

Would SDL_Delay(1) or SDL_Delay(10) be any better?

Hah. That’s platform dependent, to be on the safe side ask for a
non-zero value and hope the granularity isn’t too great (there are
plenty of threads about SDL_Delay granularity, for example google for
"Misuse of SDL_Delay?").

There was someone asking on the list some time ago why the behaviour of
SDL_Delay(0) was different under linux and under windows (IIRC windows
yields with SDL_Delay(0), while linux instantly returns). I didn’t
follow the thread closely but you might want to google it to be sure.


Glenn Maynard

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am using Lua (the extensible extension scripting language) with SDL. It
provides something very interesting : the co-routines.

Why not copy from its code source or reimplement it by yourself for the
threads which don’t really need to run concurrently ?

Co-routines are “cooperatives routines” : they stop when calling
"coroutine.yield" and may be resumed to their state to go on running with
"corouting.resume". This allows fine grained scheduling … and very faster
as it doesn’t use any OS system call (which are heavy users of CPU cycles).

Maybe you can have one coroutines pool in each thread and so some corouting
will run concurrently and you’ll have fine grained control on their
behaviour ?

Maybe I am completely aside the problem :stuck_out_tongue:

Le mardi 15 Juin 2004 00:39, Stephane Marchesin a ?crit :

Donny Viszneki wrote:

— Paul Richards <paul.richards at gmail.com> wrote:

Hi,
Is SDL_Delay(0) a good way to yeild the processor to
allow other
threads the chance to execute? I know that in
general threading
behaviour is hard to determine, but I am looking to
do the equivelant
of sched_yeild().

Why aren’t you using sched_yield?

Because sched_yield is for posix systems only, and SDL also works on
non-posix systems ?

Would SDL_Delay(1) or SDL_Delay(10) be any better?

Hah. That’s platform dependent, to be on the safe side ask for a
non-zero value and hope the granularity isn’t too great (there are
plenty of threads about SDL_Delay granularity, for example google for
"Misuse of SDL_Delay?").

There was someone asking on the list some time ago why the behaviour of
SDL_Delay(0) was different under linux and under windows (IIRC windows
yields with SDL_Delay(0), while linux instantly returns). I didn’t
follow the thread closely but you might want to google it to be sure.

Stephane


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Michel Nolard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAzsSryAKwOMHoSb0RAlu6AJ9ZZLrGKw9UMILJKrIDJR5EjHWscQCg04wy
q27MCdGP2yoRmUofhInR95Y=
=d4Lr
-----END PGP SIGNATURE-----

Interesting…

What happens if the coroutine holds a lock when you pause it and the
main thread then needs to obtain that lock? Can you define areas of
code in the coroutines which cannot be paused?

Anyhoo… I’m just being lazy using threads in this program. It could
very easily be done with async IO :).On Tue, 15 Jun 2004 11:43:07 +0200, Michel Nolard <michel.nolard at outmax.org> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am using Lua (the extensible extension scripting language) with SDL. It
provides something very interesting : the co-routines.

Why not copy from its code source or reimplement it by yourself for the
threads which don’t really need to run concurrently ?

Co-routines are “cooperatives routines” : they stop when calling
"coroutine.yield" and may be resumed to their state to go on running with
"corouting.resume". This allows fine grained scheduling … and very faster
as it doesn’t use any OS system call (which are heavy users of CPU cycles).

Maybe you can have one coroutines pool in each thread and so some corouting
will run concurrently and you’ll have fine grained control on their
behaviour ?

Maybe I am completely aside the problem :stuck_out_tongue:

Le mardi 15 Juin 2004 00:39, Stephane Marchesin a ?crit :

Donny Viszneki wrote:

— Paul Richards <@Paul_Richards> wrote:

Hi,
Is SDL_Delay(0) a good way to yeild the processor to
allow other
threads the chance to execute? I know that in
general threading
behaviour is hard to determine, but I am looking to
do the equivelant
of sched_yeild().

Why aren’t you using sched_yield?

Because sched_yield is for posix systems only, and SDL also works on
non-posix systems ?

Would SDL_Delay(1) or SDL_Delay(10) be any better?

Hah. That’s platform dependent, to be on the safe side ask for a
non-zero value and hope the granularity isn’t too great (there are
plenty of threads about SDL_Delay granularity, for example google for
"Misuse of SDL_Delay?").

There was someone asking on the list some time ago why the behaviour of
SDL_Delay(0) was different under linux and under windows (IIRC windows
yields with SDL_Delay(0), while linux instantly returns). I didn’t
follow the thread closely but you might want to google it to be sure.

Stephane


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Michel Nolard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAzsSryAKwOMHoSb0RAlu6AJ9ZZLrGKw9UMILJKrIDJR5EjHWscQCg04wy
q27MCdGP2yoRmUofhInR95Y=
=d4Lr
-----END PGP SIGNATURE-----


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Paul Richards