for(whatever)
{
    // Вычисления
    if(WAIT_OBJECT_0 == ::WaitForSingleObject(g_hStopCalculations, 0))
        return;
} // for

#include <boost/thread/mutex.hpp>
#include <boost/thread.hpp>

void DoCalculations(int i);
void UpdateProgress(int i);
bool IsUserReadyToExit();

int const stepsNumber = 10;
boost::mutex monitor;
bool goingToExit = false;

void WorkThread()
{
    for (int i = 0; i < stepsNumber; ++i)
    {
        DoCalculations(i);
        {
            boost::mutex::scoped_lock lk(monitor);
            if (goingToExit)
                return;
        }
        UpdateProgress(i);
    }
}

int main()
{
    boost::thread workThread(WorkThread);
    while (!IsUserReadyToExit()) {}
    {
        boost::mutex::scoped_lock lk(monitor);
        goingToExit = true;
    }
    workThread.join();
}

while( InterlockedExchange(&m_.l_, 1) )
{
 Sleep(1);
}

boost::mutex::scoped_lock lk(monitor);
if (goingToExit)
    return;

D>>while( InterlockedExchange(&m_.l_, 1) )
D>>{
D>> Sleep(1);
D>>}
D>>

long ret = InterlockedExchange(&target, 1);

Accesses to cacheable memory that are split across bus widths, cache lines and page boundaries are not guaranteed to be atomic by the Pentium 4, Intel Xeon, P6 family, Pentium and Intel486 processors. The Pentium 4, Intel Xeon and P6 family processors provide bus control signals that permit external memory subsystems to make split accesses atomic; however, nonaligned data accesses will seriously impact the performance of the processor and should be avoided.

...

On a multiprocessor (which C does not recognize), "sequence points" can only
be reasonably interpreted to refer to the view of memory from that
particular processor. (Otherwise the abstract model becomes too expensive
to be useful.) Therefore, volatile may say nothing at all about the
interaction between two threads running in parallel on a multiprocessor.

On a high-performance modern SMP system, memory transactions are effectively
pipelined. A memory barrier does not "flush to memory", but rather inserts
barriers against reordering of operations in the memory pipeline. For this
to have any meaning across processors there must be a critical sequence on
EACH end of a transaction that's protected by appropriate memory barriers.
This protocol has no possible meaning for an isolated volatile variable,
and therefore cannot be applied.

The protocol can only be employed to protect the relationship between two
items; e.g., "if I assert this flag then this data has been written" paired
with "if I can see the flag is asserted, then I know the data is valid".

That's how a mutex works. The mutex is a "flag" with builtin barriers
designed to enforce the visibility (and exclusion) contract with data
manipulations that occur while holding the mutex. Making the data volatile
contributes nothing to this protocol, but inhibits possibly valuable
compiler optimizations within the code that holds the mutex, reducing
program efficiency to no (positive) end.

If you have a way to generate inline barriers (or on a machine that doesn't
require barriers), and you wish to build your own low-level protocol that
doesn't rely on synchronization (e.g., a mutex), then your compiler might
require that you use volatile -- but this is unspecified by either ANSI C
or POSIX. (That is, ANSI C doesn't recognize parallelism and therefore
doesn't apply, while POSIX applies no specific additional semantics to
"volatile".) So IF you need volatile, your code is inherently nonportable.

A corollary is that if you wish to write portable code, you have no need for
volatile. (Or at least, if you think you do have a need, it won't help you
any.)

...

Accesses to cacheable memory that are split across bus widths