Re: synchronization on static bool

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On 3 Dec 2005 10:12:36 -0800, mwpa@xxxxxxxxx wrote:

>Hello,
>
>I'm using AfxBeginThread to start thread(and threre check is
>running==false), when I want to stop this thread I'm setting
>running=false, from another thread:
>
>static bool running;
>
>void MainThread()
>{
> running = true;
> CWinThread *thr = AfxBeginThread(worker,abc);
> {
> //do something, long time and after all stop worker thread
> running =false;
> }
>}
>
>UINT worker(LPVOID me)
>{
> while(true){
> if(!running)break;
> }
>}
>
>Is this solution correct? (Some weakness?)

For instructions on using CWinThread safely and a comparison of using bool
vs. an event object, see:

http://members.cox.net/doug_web/threads.htm

If you decide to stick with the bool, do declare it volatile. This will
prevent the compiler from caching its value in a register, which absent
volatile, it may do if it determines the variable cannot be modified (by
the current thread - the compiler assumes single-threading) between two
accesses of it. Besides volatile, what would prevent the compiler from
drawing such a conclusion? The main thing would be calling a function
between the two accesses that it cannot see into, such as a function
residing in an opaque DLL; the compiler would have to consider the bool
reachable from such a function. Being synchronization objects, event
objects don't have this problem. But note that this is sort of an abuse of
volatile, for the reasons given in these messages:

http://groups.google.com/groups?selm=7hl7205u4ksejokc9ormufeo02pb9i1stu%404ax.com
http://groups.google.com/groups?selm=k7fa209epgjcn2rep0rqks2ee0f4jcitgu%404ax.com

--
Doug Harrison
Visual C++ MVP
.

Relevant Pages

  • Re: volatile semantics
    ... Anything else relies upon the compiler writers making the ... A volatile qualifier won't protect you against any optimisations being ... accesses are ordered with respect to "volatile" accesses. ... That's a list of the sequence points. ...
    (comp.arch.embedded)
  • Re: volatile semantics
    ... Anything else relies upon the compiler writers making the ... A volatile qualifier won't protect you against any optimisations being ... accesses are ordered with respect to "volatile" accesses. ... extern volatile bool testPin; ...
    (comp.arch.embedded)
  • Re: synchronization on static bool
    ... >>UINT worker ... > For instructions on using CWinThread safely and a comparison of using bool ... > If you decide to stick with the bool, do declare it volatile. ... > prevent the compiler from caching its value in a register, ...
    (microsoft.public.vc.mfc)
  • Re: [PATCH tip/core/rcu 08/10] rcu: Add a TINY_PREEMPT_RCU
    ... I'd be concerned by the fact that there is no strong ordering guarantee ... My concern is that the compiler might be allowed to turn your code into: ... previous accesses to volatile objects have stabilized and no subsequent ...
    (Linux-Kernel)
  • Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
    ... It should be consistent across platforms; if not, ... as far as the compiler can take ... (or, alternatively, "other accesses to the same volatile object" ...) ...
    (Linux-Kernel)