Reply to thread

Message

[QUOTE="James Kanze, post: 3392107"]
[...]
The volatile isn't necessary.  Or rather, it isn't sufficient,
and once you have a sufficient mechanism, it isn't necessary.
(Also, most compilers---VC++, g++ and Sun CC, at least---don't
implement any significant semantics for it anyway.)

You need to synchronize the access to flag if you want this to
work.  My own solution is generally to implement a
"terminateRequested" function, which throws an exception if
flag is true, e.g.:

void
    terminateRequested()
    {
        boost::mutex::scoped_lock lock( ourTerminationMutex ) ;
        if ( ourTerminateRequestedFlag ) {
            throw TerminateRequestException() ;
        }
    }

and

void
    requestTermination()
    {
        boost::mutex::scoped_lock lock( ourTerminationMutex ) ;
        ourTerminateRequestedFlag = true ;
    }

(This more or less supposes some sort of thread object, of which
these functions are members.)

The problem is that all but the simplest classes have class
invariants that must be maintained, and that during non-const
functions, these class invariants are temporarily not
maintained: the rule is only that the invariants must hold on
entry and on exit of each function, but not during execution of
the member functions themselves.  (If maintaining the invariants
involves modifying several separate state objects, there's no
possible way that they could hold all of the time during a
member function.)

Again, I'm not 100% sure about the semantics of the function (I
generally work on Posix based systems, or more recently on
Linux), but unless the suspention is somehow differed if you are
in a critical section, the lock won't be released, and no other
thread will be able to access the objects protected by the lock.

And putting it to sleep won't solve the problem either, because
the sleeping thread will still have the lock.
[/QUOTE]

Verification