Thread: Using flag between two threads locking question

  1. #1
    Registered User
    Join Date
    Dec 2015
    Posts
    112

    Using flag between two threads locking question

    I am working in VS2015 with C++11.

    I have two threads going, and one is adding data to a queue. I have another function setting a flag of when i want to send all the data over. This variable is only used in these two threads.

    Do I need to add any locks around this flag between the two threads? Would I be better off using an atomic?

  2. #2
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Unless the flag is atomic, the behavior is undefined.
    It's not included in your description, but you also have to ensure proper synchronization when the data is transferred, i.e. a critical section. When one threads adds data, you need to lock. When one thread reads, you need to lock. A flag usually is not sufficient to ensure mutual exclusion.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #3
    Registered User
    Join Date
    Dec 2015
    Posts
    112
    I am using a mutex lock on the data I am using.

    Here is my thought on the flag. If one thread is only reading it and the other is only going to make a decision when it is true, is a lock still necessary? In other scenarios I can see a lock being 100% needed, but I'm curious about this case.

    But, I will change my data type to be an atomic regardless.

  4. #4
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Yes, if two or more threads access the same variable, then you must make it atomic or use locks around the variable.
    The reason has to do with cache consistency on the processor level.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #5
    Registered User
    Join Date
    Apr 2013
    Posts
    1,656
    Since this is VS2015, you have the option of using volatile on the flag (defaults to /volatile:ms), but this implementation of volatile is Microsoft specific. There's a note near the end of that web page: "When it relies on the enhanced guarantee that's provided when the /volatile:ms compiler option is used, the code is non-portable."

    volatile (C++)

    Last edited by rcgldr; 11-05-2016 at 06:52 AM.

  6. #6
    Registered User
    Join Date
    Apr 2013
    Posts
    1,656
    Quote Originally Posted by CodeSlapper View Post
    I am using a mutex lock on the data I am using. Here is my thought on the flag. If one thread is only reading it and the other is only going to make a decision when it is true, is a lock still necessary? In other scenarios I can see a lock being 100% needed, but I'm curious about this case.
    The main issue is potential reordering of read / write operations within the compiler or processor that don't follow the order of the written software. For example, with no memory fence, when the thread that adds data to the queue, then sets the common flag, it's possible for some the queue updates to occur after the flag is set. Using a memory fence with memory order release semantics means that both the compiler and processor will complete all writes coded before the atomic write is performed. Using a memory fence with memory order acquire semantics, means that the atomic read will complete before any any reads coded after the atomic read are performed.

    Quote Originally Posted by Elysia View Post
    Yes, if two or more threads access the same variable, then you must make it atomic or use locks around the variable.
    The reason has to do with cache consistency on the processor level.
    Almost all multi-core processors and multi-processor motherboards guarantee cache coherency. The issue is potential out of order read / writes due to compiler or processor optimization.

  7. #7
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    I use the term "cache coherency" as a universal umbrella for all issues concerning sharing data between threads, i.e. thread synchronization. It includes all the things like instruction reordering by compiler and hardware, guaranteeing that data is not cached in registers, etc.
    Last edited by Elysia; 11-05-2016 at 08:07 AM.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  8. #8
    Registered User
    Join Date
    Apr 2013
    Posts
    1,656
    Quote Originally Posted by Elysia View Post
    I use the term "cache coherency" as a universal umbrella for all issues concerning sharing data between threads, i.e. thread synchronization. It includes all the things like instruction reordering by compiler and hardware, guaranteeing that data is not cached in registers, etc.
    OK, but you should clarify your usage of the term versus the common usage:

    Cache coherence - Wikipedia

    Cache memory - Wikipedia

  9. #9
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    Quote Originally Posted by Elysia View Post
    Yes, if two or more threads access the same variable, then you must make it atomic or use locks around the variable.
    The reason has to do with cache consistency on the processor level.
    It has to do with more than that. Even before the processor comes into play, the compiler is able to make optimizations based on the assumption that is no concurrent access between threads without synchronization.

    For example, if you have a loop that reads repeatedly from a variable, aka a spin lock, that read must be atomic or else the compiler may optimize it into a single read.

    Any unsynchronized concurrent access is undefined behavior, and which means the compiler is allowed to assume that it can never happen, and may optimize based on that fact.

    Quote Originally Posted by Elysia View Post
    I use the term "cache coherency" as a universal umbrella for all issues concerning sharing data between threads, i.e. thread synchronization. It includes all the things like instruction reordering by compiler and hardware, guaranteeing that data is not cached in registers, etc.
    Then just call it a data race.
    Last edited by King Mir; 11-06-2016 at 09:21 PM.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. c++11 threads question
    By Dave11 in forum C++ Programming
    Replies: 6
    Last Post: 10-26-2014, 02:59 PM
  2. Replies: 22
    Last Post: 12-14-2012, 11:00 AM
  3. Class Scope & Locking question
    By Toonzaka in forum C++ Programming
    Replies: 2
    Last Post: 01-20-2011, 11:01 AM
  4. locking/threads hash table
    By music_man05 in forum C Programming
    Replies: 2
    Last Post: 11-04-2009, 05:20 PM
  5. locking actions to special threads
    By pheres in forum C++ Programming
    Replies: 2
    Last Post: 09-24-2008, 10:17 AM

Tags for this Thread