Another design that's usually very successful is to spawn a certain
number of worker threads at application startup (the pool can be
configured based on hardware resources, such as available RAM and
number of execution cores) and have a shared queue of work items. The
threads in the pool will pick available work items from the queue and
queue new items of work as appropriate. This is of course a rather
coarse description, but represents the essence of it.
NSOperation implements this design, and if you can make use of it
should save you work and provide you with an implementation tuned by
Apple for Mac OS X and Apple hardware.
On May 25, 2008, at 22:42, Tyson Jensen wrote:
Looking at the shark result, it seems to me that you probably have too
many threads, and are too quick to throw away a thread instead of re-
using
it. Each thread should have a specific job and be the only thread
in the
system doing that job. A job might be "responding to UI events such
as
mouse & keyboard." Another job would be "issuing OpenGL commands".
Still
another could be "run the game logic." Once started, threads should
basically keep running until the job no longer makes any sense!
(You'll want to look into thread communications, mutexes &
semaphores and
such to coordinate these threads)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/email@hidden
This email sent to email@hidden
