Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

miles vignol

memory management w/ multithreading

This topic is 5343 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

i tried running a search here, but i keep getting errors, so i''ll just go ahead and post. i''ve got a graphics app that i''m working on that i want to multi-thread. everything works fine for me, but i want the ability to abort a thread if it''s taking too long to compute. that''s not a big deal either -- i''ve gotten that to work. the issue i''m running into is managing my memory. if i allocate memory and then abort part way thru, i need some way to know to clean up the private memory the thread allocated to do the particular operation it was working on. i''ve come up with a simple linked list wrapper for malloc/free/realloc that associates a thread ID with an allocated piece of memory, but since it''s a linked list, it''s really slow when the number of memory allocations gets up there. am i approaching this the wrong way? do i just need to tune my wrapper functions to be faster or should i rethink the system?

Share this post


Link to post
Share on other sites
Advertisement
Hello miles vignol,

How are you stopping the threads?

You sould be able the signal the thread and have it clean up it self.
Or if the thread has certen points when it can check a var to see if it needs to stop you could just set the threads var and when it got around to check it would stop and clean up.

If that can''t work then use a map not a list for each thread id.
maps are faster at finding then list are going through.

Find out what the OS threads have as a way of interuputing a thread.

Just try to avoid the terminate thread cold.

Lord Bart

Share this post


Link to post
Share on other sites
lord bart:

i wanted to avoid having to write operations that check for exit conditions. since it's a geometry app, there's alot of loops going thru point and poly lists.

what i'm doing now is having the ui thread just straight out kill the process and then clean up the allocated memory.

basically, all the memory allocations are done via my wrapper and after the thread is stopped, it's trivial to go thru the master memory list and free up memory associated with a particular thread. the long process is freeing up memory specifically.

ironically, i could just comment out my memory freeing functions in the operations and it'd be fine (since there's a cleanup before exiting the thread)... but that just rubs me the wrong way. mainly because i don't want the threading aspect to really have to be considered in the actual operation...

what do you mean by a map?

my current situation is this:

a linked list (memory_thread) of linked lists (memory_block).

memory_blocks are linked to the appropriate memory_thread based on their thread id, such that the all memory_blocks of a particular memory_thread are owned by the same calling thread.

how would a map work? is that some sort of hash table or something? some of those more complex storage systems have always left me scratching my head.

i thought about even taking a public malloc implementation and adding a thread id to the mix... but that seems like a bit of overkill.

oh yeah, i'm writing this in C with SDL as the thread handler. if you're not familiar with SDL, it's cross platform library designed for low level graphics and sound operations with some UI and simple thread interaction thrown in.


[edited by - miles vignol on November 29, 2003 6:23:20 PM]

Share this post


Link to post
Share on other sites
If I was you I would probably free the memory at a convenient time (ie, when loading a level, when the game is paused, etc.).
quote:

how would a map work? is that some sort of hash table or something? some of those more complex storage systems have always left me scratching my head.


Yep, it basically associates a key with a value (in your case a thread id and memory). Although map wouldn''t work in your case because 1) it''s in the C++ standard library and 2) it doesn''t allow multiple key values.

--------
"Hey, what about those baggy pants you kids are wearin'' these days? Aren''t they hip and cool and poppin'' fresh?"-Peter Griffin
"Everytime I see an M followed by a dollar sign I just say "oh god" and go to the next post."-Neurokaotix
the D programming language

Share this post


Link to post
Share on other sites
okay, well, what i''ve done to help matters was add a simple hash table to each thread node.

basically, a thread allocation node is a thread ID and a linked list of all the pointers that malloc has given me for that thread. as i add memory, i just stuff my memory blocks onto the head of the list.

i''ve changed things to have 256 linked lists in the thread allocation node, and i''m using a simple hash function to take bits 3-10 of the pointer (returned from malloc) as my hash key. i''ll check to see what kind of distribution that yields, but it should be pretty good. it was really easy to add and it''s made things MUCH faster. i might increase the hash table size even more since there''s only 1 thread allocation node per thread and the max # of threads shouldn''t be too high...

Share this post


Link to post
Share on other sites
Hello miles vignol,

Ok your in C, well that sucks a little.
Is there a particle reason to use C, and not C++. You can always call and use C in C++.

Any way sounds like your on the right track keep memory block store by thread id. And as long as you know what thread your killing. Which you do, you just need to find the memory_tid list that holds all the memory use by that thread right.

Have the a structure that the thread used th hold all infomation about the thread. one of these info would be the list entry then right before you kill the thread go to this list entry and grab the entry. then kill hte thread and fread the memory in the list enter. Do you get what I trying to say.

When you started the thread you should pass in the use defiend structure that the funtcion the thread runs uses to store states for the thread. this is your bridge between your ui thread and the process thread. The ui give this structure or more correctly a pointer to it, and the thread use it to store suff that the calling thread (ui) would like to know, like what list it use to keep all it memory.

don''t worry about sync htis structure since it a write by process thread and read by ui thread bridge and would only be use when your killing the process thread.

Does this help some ?

Lord Bart

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Lord Bart
Ok your in C, well that sucks a little.
Is there a particle reason to use C, and not C++. You can always call and use C in C++.



Is there a particular reason you seem to think C sucks?

*mutters under breath at this guy*

quote:
vignol wrote:
ironically, i could just comment out my memory freeing functions in the operations and it''d be fine (since there''s a cleanup before exiting the thread)... but that just rubs me the wrong way. mainly because i don''t want the threading aspect to really have to be considered in the actual operation...



hmmm? if the OS takes care of the clean up, let it.

Share this post


Link to post
Share on other sites
Yes C sucks a little compare to C++ in some aspects.
Like in this case no STL containers.

But since you can do everything in C also in C++ it realy doesn't suck

Could warp a C function around the C++ map and have the your cake and eat it to.

On the freeing of memory.
I not sure about the system freeing up resources/memory form a thread.
It would depend greatly on the OS. You are only almost sure at process exit and system resource would be free. But I would not say thread is clean up only the OS stuf need to create the thread would be cleaned up. Since a thread is actual in the same memory space as the main process(main thread) how would the system know which thread a memory bolck belong to. I think it can't therefore you can assume memory will be realease back to the OS at thread termiantion.

Lord Bart


[edited by - lord bart on November 29, 2003 7:35:56 PM]

Share this post


Link to post
Share on other sites
as seems to be the case with programming, the act of describing my problem has actually given me insight into fixing it. i think it''s pretty good now...

here''s what i''m doing:

i''ve got two memory allocation functions -- one public and one private. the public allocations are the basic malloc/free functions that affect data that the whole program has access to. the private functions are designed to allocate memory for short term use for a particular function. the reason i need to tag these is to clean up in case a function is aborted by the user.

if a function does get aborted, i kill the thread and clean up it''s private memory. this version of memory cleanup is very quick because it''s simply stepping thru a list of malloc''d memory and it just free''s them one by one. it''s handled by the main/ui thread and not the OS.

if the function exits normally, it''s expected to clean up after itself (tho i do include the same cleanup function at normal termination just in case). the reason i want to do this is purely for algorithmic hygene. i don''t like the idea of just gabbing memory and assuming a garbage collection routine will straighten up after me. this is the slow part, having to search all the memory i''ve allocated for a particular block to free. this is where i''ve added the hash function and a table that''s now 1024 entries and pretty well distributed (i''m using bits 9-18 of the memory pointer).

anyway, it''s always "worked" but it was horribly slow before to free individual blocks of memory. particularly so because i was stuffing them at the begining of the list instead of the end which meant that if i free''d in the same order as they were allocated (which would happen a lot in this type of program) it would be a worse-case scenario. so now it seems to work and it''s much faster.

i use C because i like C (and never really learned C++). not to start the inevitable flame war, but C++ always struck me as a bit too much. i like the exlicitness and the terseness of C.

Share this post


Link to post
Share on other sites
Yeap I always find that after I talk about a programing problem with someelse I come up with better ways to program it to.

you should realy look at use C++, since you can still code with the erseness of C but you can use some of the tools(STL) when you need to.

basicly you can code C++ code just like C execpt the dumb stream format mess. I always default to printf and sprintf if I need to format.

But I love the constructor/destuctor for structs/class.

Lord Bart

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!