eao197 wrote:

> ... Поэтому еще раз проясню свою позицию: я хочу увидеть реальные примеры (из реальных, а не тестовых примеров), когда использовались примитивы синхронизации, но приложение все равно работало не правильно до тех пор, пока не было использовано volatile. При этом меня не интересуют ни обработчики аппаратных прерываний, ни работа с железом через отображаемые в память порты ввода/вывода.
>
> Прошу не приводить примеров, когда компилятору специальными ключами явно указывали, что ни одна функция не имеет побочных эффектов. Применение такого ключа в многопоточной программе, ИМХО, является проявлением излишнего оптимизма программиста. Кроме того, такой пример я уже видел. Может есть что-то еще?

Попытка использовать голые (не volatile) флаги вызывала очень странный behavior.
Вообще когда multithreading нечто начинает вести себя странно — ищи где ты забыл поставить volatile.

http://msdn.microsoft.com/library/en-us/vccore/html/_core_.2f.oa.2c_2f.ow.asp

Rules for Using /Oa and /Ow

If you use /Oa or /Ow, you must follow these rules. The following rules apply for any variable not declared as volatile:

No pointer can reference a variable that is used directly (a variable is referenced if it is on either side of an assignment or if a function uses it in an argument).

No variable can be used directly if a pointer to the variable is being used.

No variable can be used directly if its address is taken within a function.

No pointer can be used to access a memory location if another pointer modifies the same memory location.

Failing to follow these rules can cause corrupted data. If variables seem to take on random values, compile the program with Disable (/Od). If the problem goes away, try compiling with optimization but without /Oa or /Ow.

The following code can cause an aliasing problem:

i = -100;
while( i < 0 )
{
     i += x + y;
     *p = i;
}

Without /Oa or /Ow, the compiler assumes that the assignment to *p can modify x or y, so it does not assume that x + y is constant for each iteration. If you specify /Oa or /Ow, the compiler assumes that modifying *p does not affect x or y and the calculation of x + y can be removed from the loop.

> ME>long l;
> ME>locked::dec(l);
> ME>

> struct locked
> {
>   static long dec(volatile long& v)
>   {
>     return InterlockedDecrement(&v);
>   }
> }
>

   static long dec(long& v)
   {
     return InterlockedDecrement(&v);
   }

> PVOID InterlockedCompareExchangePointer (
>   PVOID volatile *Destination,  // destination address
>   PVOID Exchange,               // exchange value
>   PVOID Comperand               // value to compare
> );
>

long l;
long volatile* p1 = &l; // ok
long const volatile* p2 = &l; // ok
long* p3 = const_cast<long*>(p2); // cast required

Thank you for testing your code with Comeau C/C++!
Tell others about http://www.comeaucomputing.com/tryitout !

Your Comeau C/C++ test results are as follows:

Comeau C/C++ 4.3.3 (Aug  6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
Copyright 1988-2003 Comeau Computing.  All rights reserved.
MODE:strict errors C++

In strict mode, with -tused, Compile succeeded (but remember, the Comeau online compiler does not link).

1. Compiler documentation. Visual Studio в своей док-ции документирует свое implementation defined поведение volatile:
   

   ... the system always reads the current value of a volatile object at the point it is requested...

   So far so good. Также там говорится, что
   

   The volatile keyword is a type qualifier used to declare that an object can be modified in the program by something such as the operating system, the hardware, or a concurrently executing thread.

   Слов required/mandatory или даже recommended/advised мы здесь не встречаем.
   
2. Документация к API, в частности MSDN: DLLs, Processes, and Threads. Требования или даже рекоммендации использовать volatile shared variables мы здесь также не находим.
   
3. Док-ция к процессору, здесь — IA-32 Intel® Architecture Software Developer's Manual Volume 3: System Programming Guide. Здесь нам черным по белому пишут в §7.2.4:
   

   It is recommended that software written to run on Pentium 4, Intel Xeon, and P6 family processors assume the processor-ordering model or a weaker memory-ordering model. The Pentium 4, Intel Xeon, and P6 family processors do not implement a strong memory-ordering model, except when using the UC memory type. Despite the fact that Pentium 4, Intel Xeon, and P6 family processors support processor ordering, Intel does not guarantee that future processors will support this model. To make software portable to future processors, it is recommended that operating systems provide critical region and resource control constructs and API s (application program interfaces) based on I/O, locking, and/or serializing instructions be used to synchronize access to shared areas of memory in multiple-processor systems. Also, software should not depend on processor ordering in situations where the system hardware does not support this memory-ordering model.

MN>А если в подробностях ? Может статью на эту тему, а то ощущается некая нехватка собранной и структурирванной информации на эту тему, причём на русском языке (помните главную идеологию RSDN — обширный портал для руско-говорящих программистов )

MN>Как-то в одной из веток (возможно даже в этой — сейчас уже не найду) проскакивало такое заявление: поскольку явных механизмов установки барьера памяти в C++ нет, то неявным является вызов обычной функции (вроде как компилятор должен обеспечить генерацию такого кода). То есть насколько я понял вызов функции (возможно специально оформленной — естественно inline функций это не касается ) гарантировано заставляет процессор перечитывать даные из памяти и тем самым решается проблема переупорядочивании комманд. Насколько это утверждение близко к действительности, из чего оно следует и можно ли его принять на вооружение, как гарантированное средство? Вызов каких именно функции приводит к таком поведению или всех кроме подставляемых?

* записать число 1 в ячейку памяти A
* записать число 2 в ячейку памяти B
* записать число 3 в ячейку памяти С

E>Бааалин. Глухой телефон Кто обещал, что барьер можно специфицировать на конкретный объект? Если на каждый объект сделать функцию, которая обеспечивает сливание его в память на одном процессоре и всасывание в другом — разумеется, компилятор после выполнения этой функции перечитает любую часть объекта из памяти, ибо в функцию будет передаваться неконстантная ссылка

int f()
{
    char const* const p = "aaa";
    *const_cast<char*>(p) = 'b';
    const_cast<char const*&>(p) = p + 1;
}

[q]The volatile Keyword

Memory Barrier Semantics
A memory barrier is a processor instruction that preserves the ordering of read and/or write operations from the perspective of any other processor. Memory barriers include processor instructions with acquire, release, and fence semantics. These semantics describe the order in which results of an operation become visible.
• Acquire semantics mean that the results of the operation are visible before the results of any operation that appears after it in code.
• Release semantics mean that the results of the operation are visible after the results of any operation that appears before it in code.
• Fence semantics combine acquire and release semantics. The results of an operation with fence semantics are visible before those of any operation that appears after it in code and after those of any operation that appears before it.
...
On x86 and x64-based hardware (including AMD64 and the Intel Extended Memory 64 Technology), the InterlockedXxx and ExInterlockedXxx functions have both acquire and release semantics by default. The Intel Itanium architecture, however, can execute operations that have either acquire or release semantics (and not both) faster than those that have both. On Windows “Longhorn,” Microsoft plans to provide versions of the InterlockedXxx and ExInterlockedXxx functions that support either acquire or release semantics.
In addition, Microsoft CL 14.0.0 and later versions tighten the restrictions on the types of reordering that can occur around volatile variables. In these compilers, reads from volatile locations are treated as acquires and writes to volatile locations are treated as releases on hardware architectures that support these semantics.

// Кто-то, что-то готовит.
lock();
...
flag = ready;
unlock();

// Кто-то, что-то ожидает.
while( true )
    lock();
    if( ready != flag )
        unlock();
    else
        ...
        ready = not_ready;
        unlock();

An expression can result in a value and can cause side effects.

LONG f (LONG &a, LONG &b, LONG &c) {
  if (!a) {
    InterlockedIncrement (&c);
    b = a;
  }
  return b;
}

> ME>Весь мир давно заездил эту тему до дыр, только до rsdn прогрессивная мысль никак не доберется (.

> Примерно 25% этого мира посещяет RSDN на котором мы видим "луч света в темном царстве" в твоем лице.

http://groups-beta.google.com/group/comp.std.c/msg/ae49dc7a96c625f5

There are (depending on how one breaks these things down) at least three
independent issues here:


1. Atomic access granularity
2. Read/write ordering
3. Memory coherency


This discussion has been trying to address the three as if they were the
same. They're not even connected. (Or, at best, only very loosely connected.)


Most modern machines (yes, I should probably use quotes again) are designed
for fast and efficient multiprocessing. The memory interconnect is the big
bottleneck, and a lot of work has gone into streamlining the memory access
and cache protocols. Memory accesses are usually made in "chunks" not
necessarily related to the size of the data type. In general, a machine has a
few "memory access types", very likely a smaller set than the set of
instruction set types. Usually, only "memory access types" are atomic. On an
Alpha EV4 and EV5, for example, the memory access types are 32-bit "words"
and 64-bit "longwords". Smaller accesses require loading and masking a word
or longword. While some machines might choose to hide the distinction between
"memory types" and "instruction types", Alpha doesn't. To read a byte, you
must load the enclosing word/longword, (I'll use "word" for convenience from
now on), and use special instructions to mask/shift into the desired
position.


That's all fine, except when you get into concurrently executing entities
(threads, or processes using shared memory), and one tries to STORE into the
non-atomic field. To store such a field, you fetch the current word, shift &
mask (field insert) your new data, and then write the word back. If another
entity is simultaneously setting a different field in the same word, only ONE
of the two will supply a new value for the entire word, including the other
thread's field. Worse, a non-atomic field (e.g., a 16-bit short rather than a
byte) might be split between two words. If it does, you can get into trouble
even reading, because you have to read both words and combine them to create
the short value you want. Some other thread might have changed one of the
words between your two reads. That's "word tearing", and it means you've
gotten the wrong data. Of course word tearing can happen on writes, too, in
addition to the normal field access problems. Messy!


Attempting to share information between concurrently executing instruction
streams (that may be on separate processors) also requires read/write
ordering. That is, if you set a flag to signal some change in state (e.g.,
adding an item to a queue), you must be able to know that seeing the change
in the flag means you can see the new queue item. Modern SMP memory systems
frequently allow reordering of operations in the CPU to memory controller
pipeline, for all sorts of reasons (including cache synchronization issues,
speculative execution, etc.) So you may queue an item and then set a flag (or
fill in the fields of a structure and then queue it), but have the data
become visible to another processor in a different order. Unless you're
communicating between concurrently executing entities, reordering doesn't
affect you -- so it's a great performance tradeoff. But it means that when
you require ordering, you need to do something extra. One common way to force
ordering is a "memory barrier" instruction. On Alpha, for example, MB
prevents memory operation reordering across the instruction. (One could
consider a stream of memory requests in a pipe between the CPU and memory,
which can be arbitrarily reordered for implementation convenience; but the
reordering agent can't move anything past an "MB token".)


And then we've got memory coherency. A "write-through" cache may invalidate
other caches, and update main memory. But a "write-back" cache may not write
into main memory for some time. Even if other caches are invalidated, the
processors won't see the new value until it's written. That's OK, though, as
long as both processors make proper use of memory barriers. The writer puts a
memory barrier between writing the data and writing the flag (or pointer),
and the reader puts a memory barrier between reading the flag/pointer and
reading the data. Now, whenever the flag/pointer appears in memory, you know
that the data to which it points is valid -- because you can't have read it
before the flag, and the writer can't have written it after the flag.


For more information without getting too deep into processor implementation
details, see the section "Memory visibility between threads" in my book
(Programming with POSIX Threads, web link in my .sig). Curt Schimmel's
UNIX Systems for Modern Architectures (Addison-Wesley) has a section called
"Other Memory Models" that describes the SPARC architecture's "Partial Store
Ordering" (loose read/write ordering with memory barriers), though it doesn't
address word tearing.

...

The whole idea of RISC is *exactly* to make software more complex. That is, by
simplifying the hardware, hardware designers can produce more stable designs that
can be produced more quickly and with more advanced technology to result in faster
hardware. The cost of this is more complicated software. Most of the complexity is
hidden by the compiler -- but you can't necessarily hide everything. Remember that
POSIX took advantage of some loopholes in the ANSI C specification around external
calls to proclaim that you can do threaded programming in C without requiring
expensive and awkward hacks like "volatile". Still, the interpretation of ANSI C
semantics is stretched to the limit. The situation would be far better if a future
version of ANSI C (and C++) *did* explicitly recognize the requirements of threaded
programming.

...
> However, I really believe that dataA and dataB should both be declared as
> "volatile" to prevent the compiler from being too aggressive on it's
> optimization. The mutex still doesn't guarantee that the compiler hasn't
> cached the data in an internal register across a function call. My memory
> isn't perfect, but I do think this bit me on IRIX.


The existence of the mutex doesn't require this, but the semantics of POSIX and
ANSI C do require it. Remember that you lock a mutex by calling a function, passing
an address. While an extraordinarily aggressive C compiler with a global analyzer
might be able to determine reliably that there's no way that call could access the
data you're trying to protect, such a compiler is unlikely -- and, if it existed,
it would simply violate POSIX 1003.1-1996, failing to support threads.


You do NOT need volatile for threaded programming. You do need it when you share
data between "main code" and signal handlers, or when sharing hardware registers
with a device. In certain restricted situations, it MIGHT help when sharing
unsynchronized data between threads (but don't count on it -- the semantics of
"volatile" are too fuzzy). If you need volatile to share data, protected by POSIX
synchronization objects, between threads, then your implementation is busted.

...

> If you stick to a "natural machine word" that is declared as "volatile",
> you do not absolutely need a mutex (in fact I've done it). Of course, there are
> only certain cases where this works and shouldn't be done unless you really know
> your hardware architecture and what you're doing! If you have a machine with a
> lot of processors, unnecessarily locking mutexes can really kill parallelism.


> I'll give one example where this might be used:



> volatile int stop_flag = 0; /* assuming an int is atomic */


> thread_1
> {
> /* bunch of code */


> if some condition exists such that we wish to stop thread_2


> stop_flag = 1;


> /* more code — or not */
> }


> thread_2
> {
> while(1)
> {
> /* check if thread should stop */
> if (stop_flag)
> break;


> /* do whatever is going on in this loop */
> }
> }


> Of course, this assumes the hardware has some sort of cache coherency
> mechanism. But I don't believe POSIX mutex's or memory barriers (as
> defined for the DEC alpha) have any impact on cache coherency.


If a machine has a cache, and has no mechanism for cache coherency, then it can't
work as a multiprocessor.


> The example is simplistic, but it should work on a vast majority of
> systems. In fact the stop_flag could just as easily be a counter
> of some sort as long as only one thread is modifying the counter...


In some cases, yes, you can do this. But, especially with your "stop_flag",
remember that, if you fail to use a mutex (or other POSIX-guaranteed memory
coherence operation), a thread seeing stop_flag set CANNOT assume anything about
other program state. Nor can you ensure that any thread will see the changed value
of stop_flag in any particular bounded time -- because you've done nothing to
ensure memory ordering, or coherency.


And remember very carefully that bit about "as long as only one thread is
modifying". You cannot assume that "volatile" will ever help you if two threads
might modify the counter at the same time. On a RISC machine, "modify" still means
load, modify, and store, and that's not atomic. You need special instructions to
protect atomicity across that sequence (e.g., load-lock/store-conditional, or
compare-and-swap).


Am I trying to scare you? Yeah, sure, why not? If you really feel the need to do
something like this, do yourself (and your project) the courtesy of being EXTREMELY
frightened about it. Document it in extreme and deadly detail, and write that
documentation as if you were competing with Stephen King for "best horror story of
the year". I mean to the point that if someone takes over the project from you, and
doesn't COMPLETELY understand the implications, they'll be so terrified of the risk
that they'll rip out your optimizations and use real synchronization. Because this
is just too dangerous to use without full understanding.


There are ways to ensure memory ordering and coherency without using any POSIX
synchronization mechanisms, on any machine that's capable of supporting POSIX
semantics. It's just that you need to be really, really careful, and you need to be
aware that you're writing extremely machine-specific (and therefore inherently
non-portable) code. Some of this is "more portable" than others, but even the
"fairly portable" variants (like your stop_flag) are subject to a wide range of
risks. You need to be aware of them, and willing to accept them. Those who aren't
willing to accept those risks, or don't feel inclined to study and fully understand
the implications of each new platform to which they might wish to port, should
stick with mutexes.

http://groups-beta.google.com/group/comp.lang.c++/browse_frm/thread/82ea6195d505250c/ba4fc712e25a904b?q=volatile+nor+sufficient&_done=%2Fgroups%3Fie%3Dutf-8%26oe%3Dutf-8%26q%3Dvolatile+nor+sufficient%26qt_s%3DSearch+Groups%26&_doneTitle=Back+to+Search&&d#ba4fc712e25a904b

In fact, though you've said you weren't intending to advocate direct access to
any "volatile" variable without applying synchronization and casting away
"volatile", your first Gadget::Wait example does precisely that, and is wildly
incorrect and dangerously misleading. Compiler volatile semantics are not
sufficient when sharing flag_ between threads, because the hardware, as well as
the compiler, may reorder memory accesses arbitrarily, even with volatile. (Nor
would a compiler implementation that issued memory barriers at each sequence
point for volatile variables be sufficient, unless ALL data was volatile, which
is impractical and unreasonably expansive.)


Memory barriers must be applied where necessary on many architectures, and
there is no standard or portable way to generate them. There is no excuse for a
compiler to require both volatile AND memory barriers, because there's no
excuse for a compiler to reorder memory access around its own memory barrier
construct. (Usually either a compiler builtin such as Compaq C/C++ "__MB()" or
an asm("mb") "pseudocall".) The standard and portable way to ensure memory
consistency is to rely on the POSIX memory model, which is based solely on
specific POSIX API calls rather than expensive and inappropriately defined
language keywords or nonportable hardware instructions. A system or compiler
that does not provide the proper memory model (without volatile) with proper
use of the portable POSIX API calls does not conform to POSIX, and cannot be
considered for serious threading work. Volatile is irrelevant.


Entirely aside from the language issues, my point was simply that "volatile",
and especially its association with threaded programming, has been an extremely
confusing issue for many people. Simply using them together is going to cause
even more confusion. The illusory promise of volatile will lead novices into
trouble.


In contradiction to your absurd statement that "writing multithread programs
becomes impossible" without volatile, the intended C and C++ semantics
associated with volatile are neither useful nor sufficient for threaded code.
And it is WITH volatile, not without, that "the compiler wastes vast
optimization opportunities", especially as the expense of meeting the volatile
"contract" is of no benefit to threaded code.

The volatile keyword is a type qualifier used to declare that an object can be modified in the program by something other than statements, such as the operating system, the hardware, or a concurrently executing thread.

LONG InterlockedExchange(
  LPLONG volatile Target, // value to exchange
  LONG Value              // new value
);

Ш>volatile LONG var;

Ш>InterlockedExchnage(&var,1);
Ш>

Bottom line: the road to thread-safe code isn't paved with volatile

void f (int &a, int &b) {
  if (!a) {
    b = a;
  }
}

>> LONG InterlockedExchange(
>>   LPLONG volatile Target, // value to exchange
>>   LONG Value              // new value
>> );
>>

volatile LONG var;

InterlockedExchnage(&var,1);

Еще раз — без привязки к конкретной платформе volatile абсолютно бесполезен для multithreading.

E>>Если тебе удается успешно обходиться без volatile, одними примитивами — это не более, чем случайность. Весьма, впрочем, распространенная ввиду того, что нынешние оптимизаторы в большинстве случаев справедливо опасаются использовать кэшированные ранее значения после вызова неизвестной функции (тот самый aliasing, разговор о котором ты предпочел не развивать). Но, попадись такой код мощному оптимизатору, который не поленится проанализировать вызываемую функцию, или окажись примитивы синхронизации реализованными в более явном виде, этот код нормально работать перестанет. И неожиданным это будет лишь для тебя

volatile int sleep_var;

void sleep(int n) // Побочные эффекты от этой функции компилятор может оценить. См. ниже, к чему это приводит.
 {
  sleep_var=n;
 
  for(; sleep_var ;sleep_var--);
 }

long a;
volatile long b;

void f()
{
    while(!a)
        sleep(20);
}

void g()
{
    while(!b)
        sleep(20);
}

_TEXT    SEGMENT
?f@@YAXXZ PROC NEAR                    ; f, COMDAT

; 21   :     while(!a)

    mov    eax, DWORD PTR ?a@@3JA            ; a
    test    eax, eax
    jne    SHORT $L285
    mov    eax, 20                    ; 00000014H
    npad    2
$L284:

; 22   :         sleep(20);

    mov    DWORD PTR ?sleep_var@@3HC, eax        ; sleep_var
    mov    ecx, DWORD PTR ?sleep_var@@3HC        ; sleep_var
    test    ecx, ecx
    je    SHORT $L284
    npad    1
$L312:
    mov    ecx, DWORD PTR ?sleep_var@@3HC        ; sleep_var
    dec    ecx
    mov    DWORD PTR ?sleep_var@@3HC, ecx        ; sleep_var
    jne    SHORT $L312

; 21   :     while(!a)

    jmp    SHORT $L284
$L285:

; 23   : }

    ret    0
?f@@YAXXZ ENDP                        ; f
_TEXT    ENDS
PUBLIC    ?g@@YAXXZ                    ; g
; Function compile flags: /Ogtpy
;    COMDAT ?g@@YAXXZ
_TEXT    SEGMENT
?g@@YAXXZ PROC NEAR                    ; g, COMDAT

; 27   :     while(!b)

    mov    eax, DWORD PTR ?b@@3JC            ; b
    test    eax, eax
    jne    SHORT $L290
    mov    eax, 20                    ; 00000014H
    npad    2
$L289:

; 28   :         sleep(20);

    mov    DWORD PTR ?sleep_var@@3HC, eax        ; sleep_var
    mov    ecx, DWORD PTR ?sleep_var@@3HC        ; sleep_var
    test    ecx, ecx
    je    SHORT $L326
    npad    1
$L324:
    mov    ecx, DWORD PTR ?sleep_var@@3HC        ; sleep_var
    dec    ecx
    mov    DWORD PTR ?sleep_var@@3HC, ecx        ; sleep_var
    jne    SHORT $L324
$L326:
    mov    ecx, DWORD PTR ?b@@3JC            ; b
    test    ecx, ecx
    je    SHORT $L289
$L290:

; 29   : }

    ret    0
?g@@YAXXZ ENDP                        ; g
_TEXT    ENDS

1. Как конкретно помогает volatile написанию thread safe кода?
   
2. Хотелось бы увидеть кусок кода, который испрользует Interlocked* ф-ции для изменения глобальной переменной, разделяемой между потоками, и который не работал бы если переменная не volatile. Для чистоты эксперимента, объявить ф-ции Interlocked* или скопировать их реализацию без volatile.

>> void f (int &a, int &b) {
>>   if (!a) {
>>     b = a;
>>   }
>> }
>>

  int c = b;

  if (!a) {

    c++;

    b = a;

  }

  return c;

Atomicity

.....Worse still, "smart" compilers like GCC will often perform optimizations that could eliminate the memory operations needed to ensure that other processors can see what this processor has done. Fortunately, both these problems can be remedied... leaving only the relationship between access efficiency and cache line size for us to worry about.

Volatility

To prevent GCC's optimizer from buffering values of shared memory objects in registers, all objects in shared memory should be declared as having types with the volatile attribute. If this is done, all shared object reads and writes that require just one word access will occur atomically.

When operating in an MP system, IA-32 processors (beginning with the Intel486 processor) have the ability to snoop other processor’s accesses to system memory and to their internal caches. They use this snooping ability to keep their internal caches consistent both with system memory and with the caches in other processors on the bus. For example, in the Pentium and P6 family processors, if through snooping one processor detects that another processor intends to write to a memory location that it currently has cached in shared state, the snooping processor will invalidate its cache line forcing it to perform a cache line fill the next time it accesses the same memory location.

7.2.1. Memory Ordering in the Pentium® and Intel486™ Processors

The Pentium and Intel486 processors follow the processor-ordered memory model; however, they operate as strongly-ordered processors under most circumstances. Reads and writes always appear in programmed order at the system bus—except for the following situation where processor ordering is exhibited. Read misses are permitted to go ahead of buffered writes on the system bus when all the buffered writes are cache hits and, therefore, are not directed to the same address being accessed by the read miss.

In the case of I/O operations, both reads and writes always appear in programmed order.

Software intended to operate correctly in processor-ordered processors (such as the Pentium 4, Intel Xeon, and P6 family processors) should not depend on the relatively strong ordering of the Pentium or Intel486 processors. Instead, it should insure that accesses to shared variables that are intended to control concurrent execution among processors are explicitly required to obey program ordering through the use of appropriate locking or serializing operations (see Section 7.2.4., “Strengthening or Weakening the Memory Ordering Model”).

...

7.2.4. Strengthening or Weakening the Memory Ordering Model
...
It is recommended that software written to run on Pentium 4, Intel Xeon, and P6 family processors assume the processor-ordering model or a weaker memory-ordering model. The Pentium 4,
Intel Xeon, and P6 family processors do not implement a strong memory-ordering model, except when using the UC memory type. Despite the fact that Pentium 4, Intel Xeon, and P6 family processors support processor ordering, Intel does not guarantee that future processors will support this model. To make software portable to future processors, it is recommended that operating systems provide critical region and resource control constructs and API’s (application
program interfaces) based on I/O, locking, and/or serializing instructions be used to synchronize access to shared areas of memory in multiple-processor systems. Also, software should not depend on processor ordering in situations where the system hardware does not support this memory-ordering model.

tm * parsed = localtime( time( 0 ) );
int * sec = &parsed->tm_sec;
while( <something> )
    {
        <do something>
        localtime( time( 0 ) );
        if( *sec ) ...
    }

// stdafx.h : include file for standard system include files,
// or project specific include files that are used frequently, but
// are changed infrequently
//

#pragma once


#include <iostream>
#include <tchar.h>
#include <process.h>
#include <windows.h>
#include <string>

// sync_err_without_volatile.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

int  /*volatile*/ g_counter  = 0;
bool /*volatile*/ g_stopFlag = false;

CRITICAL_SECTION g_cs;

void __inline sub1();
void __inline sub2();

unsigned __stdcall Thread1(void* param)
{
  for (auto int i = 0; i < 100000000; i++)
  {
    g_counter++;
    //sub1();
  }

  EnterCriticalSection(&g_cs);
  g_stopFlag = true;
  fprintf(stdout, "\nThread1 is ended: g_counter = %u", g_counter);
  LeaveCriticalSection(&g_cs);

  return 0;
}

unsigned __stdcall Thread2(void* param)
{
  for (auto int i = 0; (i < 1000000000) && (!g_stopFlag); i++)
  {
    g_counter++;
    //sub2();
  }

  EnterCriticalSection(&g_cs);
  fprintf(stdout, "\nThread2 is ended: g_counter = %u", g_counter);
  LeaveCriticalSection(&g_cs);

  return 0;
}

void __inline sub1 (void)
{
  EnterCriticalSection(&g_cs);
  g_counter++;
  LeaveCriticalSection(&g_cs);
}

void __inline sub2 (void)
{
  EnterCriticalSection(&g_cs);
  g_counter++;
  LeaveCriticalSection(&g_cs);
}


int _tmain(int argc, _TCHAR* argv[])
{
  InitializeCriticalSection(&g_cs);

  unsigned tr_id1, tr_id2;

  HANDLE h1 = (HANDLE) _beginthreadex(NULL, 0, &Thread1, NULL, CREATE_SUSPENDED, &tr_id1);
  HANDLE h2 = (HANDLE) _beginthreadex(NULL, 0, &Thread2, NULL, CREATE_SUSPENDED, &tr_id2);

  ResumeThread(h2);
  ResumeThread(h1);
  
  getchar();
  DeleteCriticalSection(&g_cs);
  return 0;
}

> void f (int &a, int &b) {
>   if (!a) {
>     b = a;
>   }
> }
>

#include <cstdio>

void f1(int &a, int &b)
{
     if (!a)
     {
         b = a;
     }
}

void f2(int volatile &a, int &b)
{
     if (!a)
     {
         b = a;
     }
}

void f3(int &a, int &b)
{
     if (!a)
     {
         printf("0x%08x\n", &a);
         b = a;
     }
}

int main(int ac, char** av)
{
     int b;
     f1(ac, b);
     f2(ac, b);
     f3(ac, b);
     return b;
}

Command Lines    

Creating temporary file "c:\windows\temp\Vad43A.bs" with contents
[
/c  /Ox /Og /Ob2 /Oi /Ot /Oy /G6 /GF /FD /EHsc /ML /Zc:wchar_t /Zc:forScope /GR /Zi /nologo /W3 /Wp64 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /Fo"Release/" /Fd"Release/vc70.pdb" /Gd /TP
.\main.cpp
]
Creating command line "cl.exe @c:\windows\temp\Vad43A.bs"
Creating temporary file "c:\windows\temp\Vad43C.bs" with contents
[
/LTCG /OUT:"Release/exp.exe" /INCREMENTAL:NO /DEBUG /PDB:"Release/exp.pdb" /SUBSYSTEM:CONSOLE /OPT:REF /OPT:ICF /TLBID:1 /MACHINE:IX86  kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
Release\main.obj
]
Creating command line "xilink.exe @c:\windows\temp\Vad43C.bs"

--- d:\src\exp\main.cpp --------------------------------------------------------

int main(int ac, char** av)
{
     int b;
     f1(ac, b);
00401070 8B 4C 24 04      mov         ecx,dword ptr [esp+4] ; сохранили ac в ecx
00401074 85 C9            test        ecx,ecx
00401076 75 04            jne         main+0Ch (40107Ch)
00401078 33 C0            xor         eax,eax
0040107A EB 04            jmp         main+10h (401080h)
0040107C 8B 44 24 04      mov         eax,dword ptr [esp+4] ; oops, перечетали ac, видимо такая оптимизация
     f2(ac, b);
00401080 8B 54 24 04      mov         edx,dword ptr [esp+4] ; еще раз сохранили ac в ecx
00401084 85 D2            test        edx,edx
00401086 75 04            jne         main+1Ch (40108Ch)
00401088 8B 44 24 04      mov         eax,dword ptr [esp+4] ; перечитали ac, так и должно быть, volatile
     f3(ac, b);
0040108C 85 C9            test        ecx,ecx ; используем сохраненное ac в ecx
0040108E 75 16            jne         main+36h (4010A6h)
00401090 8D 44 24 04      lea         eax,[esp+4]
00401094 50               push        eax
00401095 68 FC 60 40 00   push        offset string "0x%08x\n" (4060FCh)
0040109A E8 08 00 00 00   call        printf (4010A7h)
     return b;
0040109F 8B 44 24 0C      mov         eax,dword ptr [esp+0Ch] ; перечитали ac, так и должно быть, function call
004010A3 83 C4 08         add         esp,8
}
004010A6 C3               ret

E>Если тебе удается успешно обходиться без volatile, одними примитивами — это не более, чем случайность. Весьма, впрочем, распространенная ввиду того, что нынешние оптимизаторы в большинстве случаев справедливо опасаются использовать кэшированные ранее значения после вызова неизвестной функции (тот самый aliasing, разговор о котором ты предпочел не развивать). Но, попадись такой код мощному оптимизатору, который не поленится проанализировать вызываемую функцию, или окажись примитивы синхронизации реализованными в более явном виде, этот код нормально работать перестанет. И неожиданным это будет лишь для тебя

// main.cpp

#include <stdio.h>
#include "windows.h"

extern void foo();

long a;
long b;
long volatile c;

void f()
{
    while(!a)
        Sleep(20);
    printf("%s is done\n", __FUNCTION__);
}

void g()
{
    while(!b)
        Sleep(20);
    printf("%s is done\n", __FUNCTION__);
}

void h()
{
    while(!c)
        Sleep(20);
    printf("%s is done\n", __FUNCTION__);
}

int main()
{
    foo();

    f();
    g();
    h();
}

// other.cpp

#include "windows.h"

extern long a;
extern long b;
extern long volatile c;


DWORD WINAPI thread(void*)
{
    Sleep(200);
    InterlockedIncrement(&a);
    Sleep(200);
    ++b;
    Sleep(200);
    ++c;
    return 0;
}

void foo()
{
    CreateThread(0, 0, thread, 0, 0, 0);
}

/c  /Ox /Og /Ob2 /Oi /Ot /Oy /G7 /GF /FD /ML /Zi /nologo /W4 /Wp64 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /FAs /Fa"Release/" /Fo"Release/" /Fd"Release/vc70.pdb" /Gd /TP
/OUT:"Release/volatile.exe" /INCREMENTAL:NO /DEBUG /PDB:"Release/volatile.pdb" /SUBSYSTEM:CONSOLE /OPT:REF /OPT:ICF /OPT:NOWIN98 /TLBID:1 /MACHINE:IX86  kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib 

--- d:\src\volatile\main.cpp ---------------------------------------------------

int main()
{
004010C0  push        esi  
    foo();
004010C1  call        foo (4011A0h) 

    f();
004010C6  cmp         dword ptr [a (4096C8h)],0 
004010CD  mov         esi,dword ptr [__imp__Sleep@4 (407000h)] 
004010D3  jne         main+22h (4010E2h) 
004010D5  push        14h  
004010D7  call        esi  
004010D9  cmp         dword ptr [a (4096C8h)],0 
004010E0  je          main+15h (4010D5h) 
004010E2  push        offset string "f" (407108h) 
004010E7  push        offset string "%s is done\n" (4070FCh) 
004010EC  call        printf (4011B6h) 
004010F1  add         esp,8 
    g();
004010F4  cmp         dword ptr [b (4096C0h)],0 
004010FB  jne         main+4Dh (40110Dh) 
004010FD  lea         ecx,[ecx] 
00401100  push        14h  
00401102  call        esi  
00401104  cmp         dword ptr [b (4096C0h)],0 
0040110B  je          main+40h (401100h) 
0040110D  push        offset string "g" (40710Ch) 
00401112  push        offset string "%s is done\n" (4070FCh) 
00401117  call        printf (4011B6h) 
0040111C  add         esp,8 
    h();
0040111F  cmp         dword ptr [c (4096C4h)],0 
00401126  jne         main+75h (401135h) 
00401128  push        14h  
0040112A  call        esi  
0040112C  cmp         dword ptr [c (4096C4h)],0 
00401133  je          main+68h (401128h) 
00401135  push        offset string "h" (407110h) 
0040113A  push        offset string "%s is done\n" (4070FCh) 
0040113F  call        printf (4011B6h) 
00401144  add         esp,8 
}
00401147  xor         eax,eax 
00401149  pop         esi  
0040114A  ret              
--- No source file -------------------------------------------------------------
0040114B  int         3    
0040114C  int         3    
0040114D  int         3    
0040114E  int         3    
0040114F  int         3    
--- d:\src\volatile\other.cpp --------------------------------------------------
#include "windows.h"

extern long a;
extern long b;
extern long volatile c;


DWORD WINAPI thread(void*)
{
00401150  push        esi  
    Sleep(200);
00401151  mov         esi,dword ptr [__imp__Sleep@4 (407000h)] 
00401157  push        0C8h 
0040115C  call        esi  
    InterlockedIncrement(&a);
0040115E  push        offset a (4096C8h) 
00401163  call        dword ptr [__imp__InterlockedIncrement@4 (407004h)] 
    Sleep(200);
00401169  push        0C8h 
0040116E  call        esi  
    ++b;
00401170  add         dword ptr [b (4096C0h)],1 
    Sleep(200);
00401177  push        0C8h 
0040117C  call        esi  
    ++c;
0040117E  mov         eax,dword ptr [c (4096C4h)] 
00401183  add         eax,1 
00401186  mov         dword ptr [c (4096C4h)],eax 
    return 0;
0040118B  xor         eax,eax 
0040118D  pop         esi  
}
0040118E  ret         4

/c  /Ox /Og /Ob2 /Oi /Ot /Oy /G7 /GF /FD /ML /Zi /nologo /W4 /Wp64 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /FAs /Fa"Release/" /Fo"Release/" /Fd"Release/vc70.pdb" /Gd /TP
/LTCG /OUT:"Release/volatile.exe" /INCREMENTAL:NO /DEBUG /PDB:"Release/volatile.pdb" /SUBSYSTEM:CONSOLE /OPT:REF /OPT:ICF /OPT:NOWIN98 /TLBID:1 /MACHINE:IX86  kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib 

--- d:\src\volatile\main.cpp ---------------------------------------------------

int main()
{
004010C0  push        esi  
    foo();
004010C1  call        foo (4011A0h) 

    f();
004010C6  cmp         dword ptr [a (4096C8h)],0 
004010CD  mov         esi,dword ptr [__imp__Sleep@4 (407000h)] 
004010D3  jne         main+22h (4010E2h) 
004010D5  push        14h  
004010D7  call        esi  
004010D9  cmp         dword ptr [a (4096C8h)],0 
004010E0  je          main+15h (4010D5h) 
004010E2  push        offset string "f" (407108h) 
004010E7  push        offset string "%s is done\n" (4070FCh) 
004010EC  call        printf (4011B6h) 
004010F1  add         esp,8 
    g();
004010F4  cmp         dword ptr [b (4096C0h)],0 
004010FB  jne         main+4Dh (40110Dh) 
004010FD  lea         ecx,[ecx] 
00401100  push        14h  
00401102  call        esi  
00401104  cmp         dword ptr [b (4096C0h)],0 
0040110B  je          main+40h (401100h) 
0040110D  push        offset string "g" (40710Ch) 
00401112  push        offset string "%s is done\n" (4070FCh) 
00401117  call        printf (4011B6h) 
0040111C  add         esp,8 
    h();
0040111F  cmp         dword ptr [c (4096C4h)],0 
00401126  jne         main+75h (401135h) 
00401128  push        14h  
0040112A  call        esi  
0040112C  cmp         dword ptr [c (4096C4h)],0 
00401133  je          main+68h (401128h) 
00401135  push        offset string "h" (407110h) 
0040113A  push        offset string "%s is done\n" (4070FCh) 
0040113F  call        printf (4011B6h) 
00401144  add         esp,8 
}
00401147  xor         eax,eax 
00401149  pop         esi  
0040114A  ret              
--- No source file -------------------------------------------------------------
0040114B  int         3    
0040114C  int         3    
0040114D  int         3    
0040114E  int         3    
0040114F  int         3    
--- d:\src\volatile\other.cpp --------------------------------------------------
#include "windows.h"

extern long a;
extern long b;
extern long volatile c;


DWORD WINAPI thread(void*)
{
00401150  push        esi  
    Sleep(200);
00401151  mov         esi,dword ptr [__imp__Sleep@4 (407000h)] 
00401157  push        0C8h 
0040115C  call        esi  
    InterlockedIncrement(&a);
0040115E  push        offset a (4096C8h) 
00401163  call        dword ptr [__imp__InterlockedIncrement@4 (407004h)] 
    Sleep(200);
00401169  push        0C8h 
0040116E  call        esi  
    ++b;
00401170  add         dword ptr [b (4096C0h)],1 
    Sleep(200);
00401177  push        0C8h 
0040117C  call        esi  
    ++c;
0040117E  mov         eax,dword ptr [c (4096C4h)] 
00401183  add         eax,1 
00401186  mov         dword ptr [c (4096C4h)],eax 
    return 0;
0040118B  xor         eax,eax 
0040118D  pop         esi  
}
0040118E  ret         4