Variable Pointers across Threads

Started by
25 comments, last by guywithknife 13 years ago
You should declare things that will be used by multiple threads as volatile. When you want to use the object, lock as normal and then create a non-volatile reference to the volatile object using const_cast, and make your changes through that reference.

As a bonus, because most volatile objects will generate compile errors when you try to use them, this will help you catch some threading related bugs.

To make life easier, you can make a templated class that acts as a lock/smart pointer. Its constructor takes a mutex/critical section object and a volatile object, locks the mutex/cs and initializes a non-volitile reference to the object you wanted to modify. During its lifetime it acts as like a smart pointer to the volatile objects by overloading operator * and operator ->. In its destructor unlock the mutex/cs. Make its assignment operator and copy constructor private to prevent accidents.

As a bonus, you don't need to worry about unlocking the mutex/cs if an exception gets thrown.
Chess is played by three people. Two people play the game; the third provides moral support for the pawns. The object of the game is to kill your opponent by flinging captured pieces at his head. Since the only piece that can be killed is a pawn, the two armies agree to meet in a pawn-infested area (or even a pawn shop) and kill as many pawns as possible in the crossfire. If the game goes on for an hour, one player may legally attempt to gouge out the other player's eyes with his King.
Advertisement
I've somehow managed to get it working - now whether that's by fluke or design I'm not sure. I must've have some out-of-date code, and a full rebuild finally include some of my CS stuff.

Thanks for all the help guys.

@smart_idiot: That doesn't sound like too bad an idea. Might give it a try and see what performance is like.
Out of curiosity, what multiprocessing books have you read, what is your level of programming experience, and what multiprocessing experience do you have?

Parallel processing and multiprocessing is not an easy topic. It is not something you can easily pick up from the reference documentation and a few poorly-written online tutorials.

If you are trying to jump into multiprocessing (such as threads) without enough background, you will be facing an endless procession of bugs on your own personal death march.

It is hard enough to write a program and find the bugs when everything is happening in the order you specify. When you throw concurrency issues into the mix the bug difficulty increases by an incredible amount. It is quite difficult to debug cases when your data gets corrupted in the middle of using it. You can have values modified mid-copy. You can have values be set and immediately modified to something else. You can have seemingly innocent statements cause a ripple effect of locks and resource contention that not only slow your specific process, but slow the entire OS and every programming running on it. Tiny bugs will accidentally introduce resource starvation and deadlock and other problems that only get triggered on seemingly random ways yet can never be seen in your debugger because of the way a debugger works.

Multiprocessing is generally not a good topic for anyone in "For Beginners"

Parallel processing and multiprocessing is not an easy topic. It is not something you can easily pick up from the reference documentation and a few poorly-written online tutorials.

If you are trying to jump into multiprocessing (such as threads) without enough background, you will be facing an endless procession of bugs on your own personal death march.


I'd like to add that when you are supposed to have enough background, it's still a pain in the ass.

Today newbies have a big advantage, though. In my times we didn't have more than one processing core and there were bugs that seemed to work perfectly in a computer, and then you upgraded the CPU or the RAM or tried it in a faster or slower computer, or just changed whatever and BAM! It began crashing every other time you ran it.

Nowadays it's fairly common to have a quad core, and bugs are quite more consistent with one of those :-)

[quote name='frob' timestamp='1302910644' post='4798969']
Parallel processing and multiprocessing is not an easy topic. It is not something you can easily pick up from the reference documentation and a few poorly-written online tutorials.

If you are trying to jump into multiprocessing (such as threads) without enough background, you will be facing an endless procession of bugs on your own personal death march.


I'd like to add that when you are supposed to have enough background, it's still a pain in the ass.
[/quote]


Having the requisite background knowledge reduces it from "death march" to "painful but educational", and with enough experience it becomes "mostly smooth as long as everyone follows the rules, and fun challenges with moments of moderate pain for those who broke those rules."

Both multiprocessing and network programming are common causes of programmer hair loss. Don't enter until you are ready.

Today newbies have a big advantage, though. In my times we didn't have more than one processing core and there were bugs that seemed to work perfectly in a computer, and then you upgraded the CPU or the RAM or tried it in a faster or slower computer, or just changed whatever and BAM! It began crashing every other time you ran it.

Nowadays it's fairly common to have a quad core, and bugs are quite more consistent with one of those :-)
[/quote]

More consistent, yes. But not necessarily in a way conductive to positive mental health.

Rather than giving you brief respites with the false impression that everything works, you are more likely to instead have continuous knowledge of the awful state of things.

Often the bliss of not knowing is an important part of maintaining sanity.
I would say that I'm Intermediate - Advanced at programming, but this is my first true venture into Multithreading.

The only reason I posted in For Beginners is because historically I've gotten much better help here than General Programming.

I would say that I'm Intermediate - Advanced at programming, but this is my first true venture into Multithreading.


Then, as frob implyed, you probably would like to read a serious book on the subject. I fear I can't recommend any specialized literature as the only one I know of is written in spanish and there are no translations that I'm aware of -and it's not so great anyway.

However, any book on Operative Systems should have a basic (but formal) coverage of the subject and should be an interesting reading. Operating systems concepts by Silberschatz and Galvin has a pretty neat cover and Modern Operative Systems by Andrew Tanenbaum is regarded as "The book" on OS.

Edit: When I wrote "A pretty neat cover" I didn't mean a good coverage of the subject; I have not read it but should be OK. I meant just that.
@ravengangrel:

Thanks for the recommendations. I'll check them out.
That cover is quite possibly one of the most tragic things I've ever seen....

Edit: When I wrote "A pretty neat cover" I didn't mean a good coverage of the subject; I have not read it but should be OK. I meant just that.


WTF? blink.gif

Is drug usage a common problem amongst programmers then?

This topic is closed to new replies.

Advertisement