Which comes first?

[Cubbi]

Volatile Pulse wrote:

Yes, I'm aware almost every example I evaluated in this thread is undefined, it doesn't mean there can't be a general consensus on how it should behave when it's physically encountered. I was just putting some common sense/logic behind the mysterious undefined behavior. I also enjoyed thinking about how each variable would interact in a (possible) defined case (there might be one some day, you never know).

This is indeed a temping line of thought, and I sometimes take the time to run such examples through a dozen compilers across a handful of platforms just to see what numbers they'd come up with (see http://www.cplusplus.com/forum/lounge/87236/ ), but those numbers are meaningless.

The whole point of the expression evaluation model in C (and C++, by inheritance) is to allow free reordering of the CPU instructions along independent evaluation paths to minimize memory I/O, register stalls, etc.

When the programmer introduces surprise dependencies (by modifying some variable on one path when another path is reading from it, or by modifying it from two independent paths), it's not just that first may happen after the second or second after the first (as it happens with function calls), it's really breaking the whole computation model at the lowest level.

[Volatile Pulse]

Thanks for the advice, and I'm glad you guys don't have such big egos that you can't help someone as stubborn as I am correct my ideas. I guess the hardest part for me is knowing the standard and assuming things that aren't defined as being de facto.

I read over some bits and pieces of the standard. All I can say is wow. There is so much information in there, most of which is hard to understand, but putting it into perspective and taking the time to reason it out, it makes sense. The few things I read (just randomly chose some sections) were more or less pieces that I knew. I guess the hardest part is remembering what is defined and assuming anything that's not as being undefined...that is going to take a while to learn.

My next step is going to be learning about threads. I attempted this before and the technical terms associated with threads, including mutex, kinda threw me off so I changed courses. I know threading is a theory and not something that can just be taught through a tutorial, but I've been reading up on general threading technology, understand the basic concept (mutex is a variable that's only allowed to be edited by one process at a time?) about how typically a process is used to running a specific function (calculations) while another might be used for user input. There are so many things that were included in the standard that I constantly find myself looking back over the functions and classes multiple times.

Is there a good first program to understand threads a little better? I'm not necessarily looking for code, just a concept with possibly rules, etc. I'll start a new thread once I start coding said project.

[JLBorges]

> Is there a good first program to understand threads a little better?

I suppose one could start with this series of blog posts by Anthony Williams:
http://www.justsoftwaresolutions.co.uk/threading/multithreading-in-c++0x-part-1-starting-threads.html

And then, may be, go on to his book:
http://www.amazon.com/C-Concurrency-Action-Practical-Multithreading/dp/1933988770