Re: multiple threads and volatile
- From: David Schwartz <davids@xxxxxxxxxxxxx>
- Date: Thu, 10 Jul 2008 22:15:25 -0700 (PDT)
On Jul 10, 12:15 pm, "S James S Stapleton" <stapleton...@xxxxxxx>
wrote:
Smart and knowledgeable are two separate things. In this case the matter is
completely about knowledge, something that I am attempting to obtain. I
don't mind you being less than gentle, but please keep your harsh realities
appropriate 'ignorant' would be the correct term which I'm attempting to
alleviate myself of.
He meant "smart enough" in an idiomatic way. For example, "you don't
want to set a process' CPU affinity because you are not smart enough
to know which processor it will run optimally". This doesn't literally
mean you lack intelligence, it means you don't have the information
the scheduler does. In this case, "smart" is idiomatic for something
closer to "informed".
The point he's trying to make is that when you write code to a
threading standard, you aren't smart enough to know what CPUs and
compilers it's going to run on. Some of them may not even exist yet.
Yet the standard tries to guarantee that your code will work.
This means sometimes the standard has to prohibit things that will
actually work fine or require things that everything will actually
work fine without. But if you ignore these things, and the next
version of the compiler, CPU, library, or OS expects you to follow the
standard, your code will break.
So you cannot determine whether it's safe to break the rules by
breaking them and seeing what happens.
And in this case, given the number of compilers, I don't know what all of
the potential optimizations are/could be. I just read that volatile is
useful in C to help with proper access of variables, but the document didn't
describe /why/.
It's wrong, unless by "useful" you mean changing some cases that
happen not to work into cases that happen to work, on the CPUs, OSes,
and compilers the author happened to test with. That's not a sane way
to develop code.
I've been trying to figure out why since that point.
Forget it, it's a waste of time. No threading standard in common use
specifies the use of 'volatile' is either necessary or sufficient for
synchronization or memory visibility.
Everything I saw seemed to indicate that it ensures you aren't using a
register value for the variable.
Correct. But that doesn't help you in any way. Posted write buffers
and prefetched reads create exactly the same issues as registers. And
'volatile' does nothing about those.
This would strike me as important if two
processors are using that variable, even if locks are stopping them from
simultaneous use, I don't know of any way to ensure the variable's value is
ensured to be copied from memory to register, or from register to memory.
Fortunately, you don't have to worry or care. Neither the Win32
threads conceptual machine nor the POSIX threads conceptual machine
even have registers. When you write code, you write it to the
conceptual machine for the threading standard you're using, and then
it will work on every actual machine that supports that standard.
In practice, modern machines typically solve this problem by flushing
all registers that contain cached copies of memory values to memory
after acquiring a lock and before releasing it. But that's not your
problem, it's the problem of the library and compiler folks.
DS
.
- References:
- multiple threads and volatile
- From: S James S Stapleton
- Re: multiple threads and volatile
- From: Hallvard B Furuseth
- Re: multiple threads and volatile
- From: S James S Stapleton
- multiple threads and volatile
- Prev by Date: Re: properly shutdown threads
- Next by Date: Posix threads to be created in suspended mode
- Previous by thread: Re: multiple threads and volatile
- Next by thread: Re: multiple threads and volatile
- Index(es):
Relevant Pages
|
