Thread safe memory access
Author
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?
The term you are looking for is a MUTEX, and yes, its pretty much the solution you are looking for.
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!
Also note that your approach is not thread safe!
Author
Thanks for the replies. I think the way I'll do it is to add the mutex functionality into the base IObject interface.
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.
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.
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++.
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.
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.
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.
Oh BTW, how are we accessing/running on several CPUs at all with just standard C++? :D Never mind then.
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]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
