Semaphores and mutexes

SDL Development
1

hi, i’m trying to implement some sort of thread support for mac (excluding
OSX). i know that only coorporative threading exists, but i am not sure
about semaphores and mutexes. i know very little about the mac and am
looking for suggestions and ideas. i have tried using the generic sem/mutex
files, but they get stuck in a loop with a semaphore creating a mutex, and
the mutex in turn creates a semaphore…

anyway, all of this arises as i am in need of doing multiple animations and
audio, but without using a looping structure in my main to make calls to
change animation frames and handle key inputs at the same time. i am looking
to have the animations run on timers etc…

–Keith

2

hi, i’m trying to implement some sort of thread support for mac
(excluding
OSX). i know that only coorporative threading exists, but i am not sure
about semaphores and mutexes.

SDL has no thread support in Mac OS prior to Mac OS X. If you think
about it, semaphores and mutexes are useless for cooperative threads
anyways because you can only switch threads with a specific API call,
and can’t get preempted.

We can get some broken, rather useless threads on Mac OS 9 using the
MPLibrary. But then you cannot call any Mac OS API’s (this means SDL
API’s too) from within an MP thread because the majority of these API’s
are not thread-safe.

It’s been said before and I’ll say it again. You don’t need (and
shouldn’t want) threads to create this sort of application. You need
some sort of loop somewhere to check for events, so why not update your
timers in this loop, then draw any expired timers at that time? For
anything compute-bound on a single CPU (like blitting and running your
AI), multiple threads are going to be slower that a single thread.

Some games I’ve seen don’t use timers to control animation. They either
fix the framerate by SDL_Delay() the right amount every frame or they
control their animations with time-based movement calculations instead
of frame-based ones so they run at the same speed no matter what the
framerate is.

-DOn Tuesday, May 28, 2002, at 09:20 AM, Keith Swyer wrote:

3

Hi,

giving the information it seems you want a thread to read input and one to
update animations, right? Therefore you don’t need concurrency by my means.
Letting animations run on timer requests for Events, not threads… And if
you use threads, you should use a Conditional Wait or something, but I would
not know if this uses an implementation which given problems on your mac…

Good luck, Patrick.

On Tue, 28 May 2002 11:20:34 -0300 “Keith Swyer”
wrote.
hi, i’m trying to implement some sort of thread support for mac (excluding
OSX). i know that only coorporative threading exists, but i am not sure
about semaphores and mutexes. i know very little about the mac and am
looking for suggestions and ideas. i have tried using the generic sem/mutex
files, but they get stuck in a loop with a semaphore creating a mutex, and
the mutex in turn creates a semaphore…

anyway, all of this arises as i am in need of doing multiple animations and
audio, but without using a looping structure in my main to make calls to
change animation frames and handle key inputs at the same time. i am
looking>to have the animations run on timers etc…

–Keith

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

4

ok, i’m understanding this a little better now…and the mac thread
problems make sense now. i firuged there would be problems with them being
coorporative, but couldn’t think of how else to try and get things to work.
i know you mentioned the logical timer stuff before, but i just didn’t quite
understand enough; i do a bit better now. i guess i’m a little thick headed
sometimes. anyway, what about using the mac TimeManager to implement the
SDL_Addtimer and the SDL_Settimer ?? would this not work? and possibly
acomplish what i’m trying to do also? again, i’m not too familar with the
mac (obviously), but this seems like it should work. I guess i just see the
logical timer stuff and checking in the event loop to be messier and more of
a hastle than if i can find another way. but again, any comments or
suggestions are helpful. and if the logical timer is the best way to go in
the end…i’ll do it, but may need a little help in understanding it.

the way i see it now, is that if i have say 30 different timed events , i’d
have to check each time through the event processing loop to see if that
timed event should be processed, and if so do it?

thanks,
–Keith> On Tuesday, May 28, 2002, at 09:20 AM, Keith Swyer wrote:

hi, i’m trying to implement some sort of thread support for mac
(excluding
OSX). i know that only coorporative threading exists, but i am not sure
about semaphores and mutexes.

SDL has no thread support in Mac OS prior to Mac OS X. If you think
about it, semaphores and mutexes are useless for cooperative threads
anyways because you can only switch threads with a specific API call,
and can’t get preempted.

We can get some broken, rather useless threads on Mac OS 9 using the
MPLibrary. But then you cannot call any Mac OS API’s (this means SDL
API’s too) from within an MP thread because the majority of these API’s
are not thread-safe.

It’s been said before and I’ll say it again. You don’t need (and
shouldn’t want) threads to create this sort of application. You need
some sort of loop somewhere to check for events, so why not update your
timers in this loop, then draw any expired timers at that time? For
anything compute-bound on a single CPU (like blitting and running your
AI), multiple threads are going to be slower that a single thread.

Some games I’ve seen don’t use timers to control animation. They either
fix the framerate by SDL_Delay() the right amount every frame or they
control their animations with time-based movement calculations instead
of frame-based ones so they run at the same speed no matter what the
framerate is.

-D

5

hi, i’m trying to implement some sort of thread support for mac
(excluding
OSX). i know that only coorporative threading exists, but i am not
sure
about semaphores and mutexes.

SDL has no thread support in Mac OS prior to Mac OS X. If you think
about it, semaphores and mutexes are useless for cooperative threads
anyways because you can only switch threads with a specific API call,
and can’t get preempted.

ok, i’m understanding this a little better now…and the mac thread
problems make sense now. i firuged there would be problems with them
being
coorporative, but couldn’t think of how else to try and get things to
work.
i know you mentioned the logical timer stuff before, but i just didn’t
quite
understand enough; i do a bit better now. i guess i’m a little thick
headed
sometimes. anyway, what about using the mac TimeManager to implement the
SDL_Addtimer and the SDL_Settimer ?? would this not work?

I haven’t verified this myself, but a recent post mentioned that the
timer implementation on Mac OS 9 only allows a single timer. It isn’t
clear to me why this is the case. With timers on Mac OS 9 you might find
things difficult since synchronization primitives don’t work. Timers on
Mac OS 9 (IIRC) can interrupt your program at any time.

and possibly
acomplish what i’m trying to do also? again, i’m not too familar with
the
mac (obviously), but this seems like it should work. I guess i just see
the
logical timer stuff and checking in the event loop to be messier and
more of
a hastle than if i can find another way. but again, any comments or
suggestions are helpful. and if the logical timer is the best way to go
in
the end…i’ll do it, but may need a little help in understanding it.

the way i see it now, is that if i have say 30 different timed events ,
i’d
have to check each time through the event processing loop to see if that
timed event should be processed, and if so do it?

Yep. With only 30 things to check for, you won’t be spending much time
doing the checks yourself:

Uint32 time = SDL_GetTicks();

for (int i = 0; i < num_events; i++) {

if (event[i]->expire <= time) {
	doEvent(event[i]);
	event[i]->expire = time + event[i]->interval;
}

}

Seems easier than figuring out all the places that need mutex locks.

-DOn Tuesday, May 28, 2002, at 10:32 AM, Keith Swyer wrote:

On Tuesday, May 28, 2002, at 09:20 AM, Keith Swyer wrote:

6

Keith Swyer wrote:>>On Tuesday, May 28, 2002, at 09:20 AM, Keith Swyer wrote:

hi, i’m trying to implement some sort of thread support for mac
(excluding
OSX). i know that only coorporative threading exists, but i am not sure
about semaphores and mutexes.

SDL has no thread support in Mac OS prior to Mac OS X. If you think
about it, semaphores and mutexes are useless for cooperative threads
anyways because you can only switch threads with a specific API call,
and can’t get preempted.

We can get some broken, rather useless threads on Mac OS 9 using the
MPLibrary. But then you cannot call any Mac OS API’s (this means SDL
API’s too) from within an MP thread because the majority of these API’s
are not thread-safe.

It’s been said before and I’ll say it again. You don’t need (and
shouldn’t want) threads to create this sort of application. You need
some sort of loop somewhere to check for events, so why not update your
timers in this loop, then draw any expired timers at that time? For
anything compute-bound on a single CPU (like blitting and running your
AI), multiple threads are going to be slower that a single thread.

Some games I’ve seen don’t use timers to control animation. They either
fix the framerate by SDL_Delay() the right amount every frame or they
control their animations with time-based movement calculations instead
of frame-based ones so they run at the same speed no matter what the
framerate is.

-D

ok, i’m understanding this a little better now…and the mac thread
problems make sense now. i firuged there would be problems with them being
coorporative, but couldn’t think of how else to try and get things to work.
i know you mentioned the logical timer stuff before, but i just didn’t quite
understand enough; i do a bit better now. i guess i’m a little thick headed
sometimes. anyway, what about using the mac TimeManager to implement the
SDL_Addtimer and the SDL_Settimer ?? would this not work? and possibly
acomplish what i’m trying to do also? again, i’m not too familar with the
mac (obviously), but this seems like it should work. I guess i just see the
logical timer stuff and checking in the event loop to be messier and more of
a hastle than if i can find another way. but again, any comments or
suggestions are helpful. and if the logical timer is the best way to go in
the end…i’ll do it, but may need a little help in understanding it.

the way i see it now, is that if i have say 30 different timed events , i’d
have to check each time through the event processing loop to see if that
timed event should be processed, and if so do it?

thanks,
–Keith

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

Perhaps with your 30 different events you could organize them into a
queue, sorted by time till execution. SDL_Delay() a millsec or two,
look again. Repeat. Or SDL_Delay() till the first event should be run.
(Hmmm, I’ve never tried to SDL_Delay() on OS9, I wonder how that even
works.) Of course every time that you hand control outside of the
program you have to trust the OS and other programs to give control back
when you want.

In any case, I think doing ‘fake’ timers yourself would work much much
better than some multithreaded or other external hack. In my
experience, the single loop approach accepts input promptly and can be
made to operate smoothly. Especially on OS9… darn that OS runs my
game smoothly (the best I’ve seen).

I am fairly confident that the easiest, most probable to work, and
probably best working method is to not rely on external timers and/or
sceduling. Do it yourself.

                                            -ray skoog
7

I haven’t verified this myself, but a recent post mentioned that the
timer implementation on Mac OS 9 only allows a single timer. It isn’t
clear to me why this is the case.

Nobody who knows MacOS programming has bothered to update the MacOS timer
code since multiple timers went into the API. It looks like it could easily
be done though. :slight_smile:

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

8

[…]

Yep. With only 30 things to check for, you won’t be spending much time
doing the checks yourself:

Uint32 time = SDL_GetTicks();

for (int i = 0; i < num_events; i++) {

if (event[i]->expire <= time) {
doEvent(event[i]);
event[i]->expire = time + event[i]->interval;
}
}

Seems easier than figuring out all the places that need mutex locks.

I’d say it’s also more efficient, more accurate and more reliable.
(Except possibly if you’re running on a real time OS…)

//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 28 May 2002 17:53, Darrell Walisser wrote: