Sign in to follow this  
f8k8

Thread safe memory access

Recommended Posts

f8k8    171
What's the best way to ensure thread safe memory access? Say I have a block of memory, and I want to launch a number of threads to process it in some way, then read back the results once the processing has finished, should I make a copy of the memory for the threads, then copy it back once they're done, or just use the same memory but access it through a wrapper class that holds the state of the memory, e.g. LOCKED_FOR_PROCESSING, LOCKED_BY_THREAD, THREAD_DONE, then set it to LOCKED_FOR_PROCESSING before starting the thread, have the thread set it to LOCKED_BY_THREAD while it's running then THREAD_DONE when the thread is done. That way, I can create a number of wrappers and set them to LOCKED_FOR_PROCESSING at creation time, create the threads and then wait until they are all set to THREAD_DONE before using the processed data. Does that sound like a good idea?

Share this post


Link to post
Share on other sites
IndyJones    298
I'd use a wrapper class exposing read and write functions that use a critical section to ensure that only one thread at a time will access the memory. To get more information about critical section check out MSDN (you can starthere).
Also note that your approach is not thread safe!

Share this post


Link to post
Share on other sites
f8k8    171
Thanks for the replies. I think the way I'll do it is to add the mutex functionality into the base IObject interface.

Share this post


Link to post
Share on other sites
_winterdyne_    530
I'd advise using the whatever platform API your working with's built-in mutexes within a wrapper. For example I use Win32 and Posix mutexes in precisely the same way because I wrapped them. Otherwise you're left with the unfortunate task of handing off execution of a thread whilst waiting for a home-rolled mutex to become free. That sort of thing is messy, and difficult to maintain.

Also, making a mutex part of a generic object isn't necessarily a good solution - some types of object may need interaction from many different threads, at varying times - just mutex the specific blocks of code you need to.


Share this post


Link to post
Share on other sites
CTar    1134
If you need a cross-platform solution you should look into Boost.Thread, it even have thread-specific-storage (tss). Your solution sounds good, but it's impossible to actually make work in every case. C++ wasn't written with threading in mind, and it's impossible (not hard, or very inefficient, just impossible) to write critical section like code in standard C++.

Share this post


Link to post
Share on other sites
Jan Wassenberg    999
Quote:
C++ wasn't written with threading in mind, and it's impossible (not hard, or very inefficient, just impossible) to write critical section like code in standard C++.

That is a bit pessimistic :) There are software-only approaches like Peterson's Algorithm that do not require special OS or CPU support.

Share this post


Link to post
Share on other sites
CTar    1134
Quote:
Original post by Jan Wassenberg
That is a bit pessimistic :) There are software-only approaches like Peterson's Algorithm that do not require special OS or CPU support.


From the article:
Quote:
Many modern CPUs execute their instructions in an out-of-order fashion. This algorithm won't work on SMP machines equipped with those CPUs.

In most cases you will be able to implement something, but it's not possible to make an algorithm work in all cases.

Share this post


Link to post
Share on other sites
Jan Wassenberg    999
Oh come on, that's a bit of a stretch. Yes, by postulating an SMP system with a (too?) weak memory model, you can break just about anything.
Oh BTW, how are we accessing/running on several CPUs at all with just standard C++? :D Never mind then.

Share this post


Link to post
Share on other sites
CTar    1134
Quote:
Original post by Jan Wassenberg
Oh come on, that's a bit of a stretch. Yes, by postulating an SMP system with a (too?) weak memory model, you can break just about anything.
Oh BTW, how are we accessing/running on several CPUs at all with just standard C++? :D Never mind then.


Ok, that might be stretching it a bit, just skimmed the article and saw it. Anyway I'll try to look into the C code and see if I can find any real problems.

EDIT: Ok, I admit, it's possible, but a better idea using functionality for threading provided by the OS.

[Edited by - CTar on April 7, 2006 11:19:35 AM]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this