Threads priority

How can I change the priority of an SDL_Thread?

Also, could anyone tell me what a mutex is and/or point me to some concurrent programming tutorial?

How can I change the priority of an SDL_Thread?

You can’t do that in a portable way.

Either way;

1) It most probably won't have the effect you want.

2) The effects differ between platforms.

3) Most operating systems can do what you want
   automatically - no need for special "hints".

Properly designed applications usually don’t need to mess with priorities

  • and if they need to, the requirements usually rule out many platforms
    (since they simply cannot do what you want), and require custom code and
    tuning for each of the platforms that can fulfil the requirements.

In short, forget about priorities. What’s the actual problem you’re
trying to solve?

Also, could anyone tell me what a mutex is and/or point me to some
concurrent programming tutorial?

A mutex is a MUTually EXclusive synchronization construct. The basic idea
is that only one thread can “own” a particular mutex at any one time.
Most frequently used when you need to share objects between threads,
while ensuring that there are no “uncontrolled” collisions. A mutex
usually also supports “blocking”, to have threads automatically wait for
their turn when trying to lock an object. (Spinning - ie busy waiting
until the mutex is released - works only if the mutex owner is running on
another CPU.)

Don’t know of any tutorials, unfortunately.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Friday 10 May 2002 19:32, CRV?ADER/KY wrote:

hi!

?Also, could anyone tell me what a mutex is and/or point me to some
?concurrent programming tutorial?

A mutex is a MUTually EXclusive synchronization construct. The basic idea
is that only one thread can “own” a particular mutex at any one time.
Most frequently used when you need to share objects between threads,
while ensuring that there are no “uncontrolled” collisions. A mutex
usually also supports “blocking”, to have threads automatically wait for
their turn when trying to lock an object. (Spinning - ie busy waiting
until the mutex is released - works only if the mutex owner is running on
another CPU.)

Don’t know of any tutorials, unfortunately.

i don’t know any tutorials either, but you should grab a copy of “Unix Network
Programming” (Vol.1 or Vol.2) by Richard W. Stevens. they are really good.
also, there are some examples about thread programming at:
http://www.kohala.com/start/ (that’s stevens’ homepage).
and finally, if you won’t be confused too much, you might want to look into the SDL
sources: SDL-1.2/src/thread/SDL_sysmutex.c appears quite useful to me aswell.

good luck then!

regards,
Tolga Dalman.________________________________________________________________
Keine verlorenen Lotto-Quittungen, keine vergessenen Gewinne mehr!
Beim WEB.DE Lottoservice: http://tippen2.web.de/?x=13

How can I change the priority of an SDL_Thread?

You can’t do that in a portable way.

Either way;

  1. It most probably won’t have the effect you want.

  2. The effects differ between platforms.

  3. Most operating systems can do what you want
    automatically - no need for special “hints”.

What do you mean with “automatically”?

Properly designed applications usually don’t need to mess with priorities

  • and if they need to, the requirements usually rule out many platforms
    (since they simply cannot do what you want), and require custom code and
    tuning for each of the platforms that can fulfil the requirements.

In short, forget about priorities. What’s the actual problem you’re
trying to solve?

uh… it was just a theoretical question… however an
int SDL_Priority(SDL_Thread * target, int priority)
(where priority is a Linux-style number between -20 and 20 (Windows values “idle” through “realtime” should be
obtained with an interpolation) and the return value can be SUCCESS, NO_OS_SUPPORT or NO_PERMISSION)
would be cool.

Also, could anyone tell me what a mutex is and/or point me to some
concurrent programming tutorial?

A mutex is a MUTually EXclusive synchronization construct. The basic idea
is that only one thread can “own” a particular mutex at any one time.
Most frequently used when you need to share objects between threads,
while ensuring that there are no “uncontrolled” collisions. A mutex
usually also supports “blocking”, to have threads automatically wait for
their turn when trying to lock an object. (Spinning - ie busy waiting
until the mutex is released - works only if the mutex owner is running on
another CPU.)

thanks.

CRV?ADER/KY wrote:

How can I change the priority of an SDL_Thread?

You can’t do that in a portable way.

Either way;

  1. It most probably won’t have the effect you want.

  2. The effects differ between platforms.

  3. Most operating systems can do what you want
    automatically - no need for special “hints”.

What do you mean with “automatically”?

He means that thread priority rarely does what anyone thinks it does. If
your code is properly designed then threads that have nothing to do will
be blocked and threads that can run will not be blocked. So, what you
think of as low priority threads will be blocked most of the time.
Setting the priority lower usually gets you threads that never run.
Setting it higher gets you threads that never stop. At least that
represents the experience I had when I was first learning to program
with threads and found that thread priority is something that is best
ignored. Well designed code doesn’t need it, and poorly designed code
can’t be made to work correctly with it.

Usually people make the mistake of thinking that if they have a two
threads, one with a slightly higher priority and one with a slightly
lower priority the high priority thread with run most of the time and
the low priority thread with run once in a while. That’s not what
happens the high priority thread runs all the time and the low priority
thread never runs.

Yeah… I remember the time I spent a day trying to figure out why out
of a group of equal priority threads some of them never ran… Turns out
that that is the way threads were defined that system. If more than one
thread was ready and they all had equal priorities it was pretty much
luck that determined which ones would run, and some never got lucky. So,
I played with the priorities, and wound up with only one thread that
ever ran…

The moral of the story: look up the concept of communicating sequential
processes and learn it.

	Bob P.

How can I change the priority of an SDL_Thread?

You can’t do that in a portable way.

Either way;

  1. It most probably won’t have the effect you want.

  2. The effects differ between platforms.

  3. Most operating systems can do what you want
    automatically - no need for special “hints”.

What do you mean with “automatically”?

Any serious scheduler will build statistics and analyze the behavior of
threads and processes. Based on this data, the scheduler will dynamically
adjust thread/process priority, so that “nice” loop { do work; got to
sleep; } threads and CPU hogs that rarely sleep, can coexist nicely.

That is, if you have a video thread that eats all CPU it can get, and an
audio thread that wakes up occasionally to generate one buffer, the
latter will automatically get a higher dynamic priority than the former.
the result is that such a configuration “just works” - no need to fiddle
with explicit thread priorities. (On “normal” operating systems, at
least. Primitive real time OSes may differ, for example.)

Properly designed applications usually don’t need to mess with
priorities - and if they need to, the requirements usually rule out
many platforms (since they simply cannot do what you want), and
require custom code and tuning for each of the platforms that can
fulfil the requirements.

In short, forget about priorities. What’s the actual problem you’re
trying to solve?

uh… it was just a theoretical question… however an
int SDL_Priority(SDL_Thread * target, int priority)
(where priority is a Linux-style number between -20 and 20 (Windows
values “idle” through “realtime” should be obtained with an
interpolation) and the return value can be SUCCESS, NO_OS_SUPPORT or
NO_PERMISSION) would be cool.

Well, maybe, but I’m worried that it might just cause portability
problems without really doing anything useful. Priorities and scheduling
policies are very platform specific matters, so designing for any
specific non-standard setup would be dangerous.

For example, one could support FIFO scheduling policies (commonly used
for real time threads - allows you to hold the CPU forever) - but if you
develop an application using that on Windows, it’s easy to make a mistake
that will freeze a Linux system totally, while appearing to work
correctly on Windows. The reason for that is that Windows doesn’t have
FIFO scheduling at all, while Linux does. Besides, FIFO scheduling is
only truly useful with lowlatency and/or kpreempt patches or
development/future Linux kernels (which include derivates of these
patches), and it’s only available to root and users with special caps.

Another example would be priorities. If you set up two CPU hogging
threads, you might adjust their CPU time balance by tweaking their
priorities. However, the results would be very different on different
platforms. Possibly different enough that your application won’t work
correctly on some platforms.

In short, I’d say this stuff is best hand tuned on a per platform basis,
if you really need to mess with it at all. First try “inherently
stable” designs that don’t need priority tweaking to work properly.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 14 May 2002 19:47, CRV?ADER/KY wrote:

[…]

Usually people make the mistake of thinking that if they have a two
threads, one with a slightly higher priority and one with a slightly
lower priority the high priority thread with run most of the time and
the low priority thread with run once in a while. That’s not what
happens the high priority thread runs all the time and the low priority
thread never runs.

…if you’re using FIFO scheduling, at least. A time sharing OS would
eventually allow the lower priority thread to breathe now and then - but
I’m quite sure most people would be rather surprized when they see the
actual result of that. (It’s hardly done on a per frame basis, to put it
in game terms. :slight_smile:

Yeah… I remember the time I spent a day trying to figure out why out
of a group of equal priority threads some of them never ran… Turns
out that that is the way threads were defined that system. If more than
one thread was ready and they all had equal priorities it was pretty
much luck that determined which ones would run, and some never got
lucky. So, I played with the priorities, and wound up with only one
thread that ever ran…

Interesting. What OS was that? (Sounds like an RTOS with FIFO scheduling
only, as well as a generally weird way of scheduling. :wink:

The moral of the story: look up the concept of communicating sequential
processes and learn it.

Yes indeed. Not considering multiprocessor systems (which require threads
for a single application to use more than one CPU at a time), threading
is basically a different programming style, rather than a different way
of executing code.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 15 May 2002 00:25, Bob Pendleton wrote:

David Olofson wrote:

[…]

Yeah… I remember the time I spent a day trying to figure out why out
of a group of equal priority threads some of them never ran… Turns
out that that is the way threads were defined that system. If more than
one thread was ready and they all had equal priorities it was pretty
much luck that determined which ones would run, and some never got
lucky. So, I played with the priorities, and wound up with only one
thread that ever ran…

Interesting. What OS was that? (Sounds like an RTOS with FIFO scheduling
only, as well as a generally weird way of scheduling. :wink:

Not an OS, it was Java on Windows. I tried to file a bug report and was
told that that was the way threads were defined to work. It is the
result of portability issues with thread libraries across different OSes
and implementations. You can’t ensure that equal priority threads will
ever run. If you look at the theoretical descriptions of things like
condition waits and condition broadcasts you see where the problem comes
from. That same problem in Java is coupled with the problem of
non-interruptable IO which gets into the whole problem caused by the
lack of a select or poll in Java (finally fixed in SDK 1.4). All of that
driven by portability problems. This is OT so I won’t go into more deeply.

The moral of the story: look up the concept of communicating sequential
processes and learn it.

Yes indeed. Not considering multiprocessor systems (which require threads
for a single application to use more than one CPU at a time), threading
is basically a different programming style, rather than a different way
of executing code.

Yep, think of you threads as worker in an assembly line who wait until
there is something to do, do it, and pass it along to the next worker
bee on the line.> On Wednesday 15 May 2002 00:25, Bob Pendleton wrote:

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -’


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


±-----------------------------------------+

  • Bob Pendleton, an experienced C/C++/Java +
  • UNIX/Linux programmer, researcher, and +
  • system architect, is seeking full time, +
  • consulting, or contract employment. +
  • Resume: http://www.jump.net/~bobp +
  • Email: @Bob_Pendleton +
    ±-----------------------------------------+

I got exactly such behavior on Solaris with pthreads. The native threads
seemed to work in a more intuitive way, but I needed portability… lesson
learned.
JacekOn Wed, May 15, 2002 at 04:05:03AM +0200, David Olofson wrote:

On Wednesday 15 May 2002 00:25, Bob Pendleton wrote:

Yeah… I remember the time I spent a day trying to figure out why out
of a group of equal priority threads some of them never ran… Turns
out that that is the way threads were defined that system. If more than
one thread was ready and they all had equal priorities it was pretty
much luck that determined which ones would run, and some never got
lucky. So, I played with the priorities, and wound up with only one
thread that ever ran…

Interesting. What OS was that? (Sounds like an RTOS with FIFO scheduling
only, as well as a generally weird way of scheduling. :wink:


±------------------------------------+
|from: J.C.Wojdel |
| J.C.Wojdel at cs.tudelft.nl |
±------------------------------------+

Hi,
I don’t know how to reply to a single message in the digest very well, but
here is some information on threads, mutexes, etc. (sorry if someone else
has already answered this, however I have a big backlog here)


http://www.llnl.gov/computing/tutorials/workshops/workshop/pthreads/MAIN.html
http://doc.in2p3.fr/kcc/Current/doc/tutorials/threads.html
http://developerlife.com/lessons/advancedthreads/default.htm

Some good books are mentioned here:
http://www.honeylocust.com/books/java/

HTH,
Jeff

How can I change the priority of an SDL_Thread?
You can’t do that in a portable way.
Either way;
=091) It most probably won’t have the effect you want.
=092) The effects differ between platforms.
=093) Most operating systems can do what you want
=09 automatically - no need for special “hints”.

Properly designed applications usually don’t need to mess with priorities=
=20

  • and if they need to, the requirements usually rule out many platforms=20
    (since they simply cannot do what you want), and require custom code and=20
    tuning for each of the platforms that can fulfil the requirements.
    In short, forget about priorities. What’s the actual problem you’re=20
    trying to solve?

Also, could anyone tell me what a mutex is and/or point me to some
concurrent programming tutorial?
A mutex is a MUTually EXclusive synchronization construct. The basic idea=
=20
is that only one thread can “own” a particular mutex at any one time.=20
Most frequently used when you need to share objects between threads,=20
while ensuring that there are no “uncontrolled” collisions. A mutex=20
usually also supports “blocking”, to have threads automatically wait for=20
their turn when trying to lock an object. (Spinning - ie busy waiting=20
until the mutex is released - works only if the mutex owner is running on=
=20
another CPU.)
Don’t know of any tutorials, unfortunately.

//David Olofson — Programmer, Reologica Instruments ABOn Friday 10 May 2002 19:32, CRV?ADER/KY wrote: