Am I the only one that thinks it''s ridiculous to create and destroy processes in an attempt to gain MT performance and automate the clean-up?
Make a thread pool, make the threads work, don''t terminate any of them until the entire app exits. Use a semaphore to synchronize the work load and a condition variable to signal when it''s time to exit and another cv to signal an abort the current operation.
memory management w/ multithreading
Author
as for critical sections, that''s being dealt with via locks (mutex''s). the memory management uses these to keep two threads from trying to manipulate the memory structures at the same time.
the reason for creating threads and allowing them to be terminated is that i don''t want to get into having to write special code to routinely check for a particular exit condition. it seems easier to just start a thread when needed and then kill the thread if you need it to abort (or let it just finish on its own). perhaps there''s a performance hit, but i suspect there''d also be a performance hit if you''re constantly checking a variable to see if the system should abort itself.
the way i''m doing things now, i''ve got operations that rely on other operations. if an operation only has a single input, then there''s no thread created, it just executes that sub-operation and returns to continue the parent operation.
there''s no real way i can figure to pre-validate parameters. certainly i can check for errors, but if somebody wants to subdivide a piece of geometry into a particular number of polys, who am i to say they shouldn''t? because of the plug and unplug nature, i anticipate that somebody might plug something together they might not exactly have meant to, so perhaps two long operations might get stuck together than not only take forever, but return results that aren''t even useful.
also, there''s the aspect of updates. when a parameter is altered, it forces a recomputation of the geometry chain. but if the user is actually wanting to alter 3 or 4 parameters, it seems like torture to make them wait for a computation cycle after each. certainly they could alter their work habits to get around this, but i''d rather give them the control to pre-empt a task currently running.
the reason for creating threads and allowing them to be terminated is that i don''t want to get into having to write special code to routinely check for a particular exit condition. it seems easier to just start a thread when needed and then kill the thread if you need it to abort (or let it just finish on its own). perhaps there''s a performance hit, but i suspect there''d also be a performance hit if you''re constantly checking a variable to see if the system should abort itself.
the way i''m doing things now, i''ve got operations that rely on other operations. if an operation only has a single input, then there''s no thread created, it just executes that sub-operation and returns to continue the parent operation.
there''s no real way i can figure to pre-validate parameters. certainly i can check for errors, but if somebody wants to subdivide a piece of geometry into a particular number of polys, who am i to say they shouldn''t? because of the plug and unplug nature, i anticipate that somebody might plug something together they might not exactly have meant to, so perhaps two long operations might get stuck together than not only take forever, but return results that aren''t even useful.
also, there''s the aspect of updates. when a parameter is altered, it forces a recomputation of the geometry chain. but if the user is actually wanting to alter 3 or 4 parameters, it seems like torture to make them wait for a computation cycle after each. certainly they could alter their work habits to get around this, but i''d rather give them the control to pre-empt a task currently running.
Author
the deadlock issue i''m running into is because of the way SDL kills a signal. it warns that it''s not the best way and suggests that sending a signal to the thread is a better system. sounds good to me. but how the F do you send a signal in windows? i suppose raise() might work for me here, but i was hoping for kill()...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
