function-level variables and threads

This is a discussion on function-level variables and threads within the C++ Programming forums, part of the General Programming Boards category; have a weird bug, allow me a sanity check, please. consider: Code: void foo(const std::vector<int>&v,unsigned int start,unsigned int stop,unsigned int& ...

  1. #1
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839

    function-level variables and threads

    have a weird bug, allow me a sanity check, please. consider:

    Code:
    void foo(const std::vector<int>&v,unsigned int start,unsigned int stop,unsigned int& sum)
    {
        unsigned int x;
        for(x=start;x<stop;++x)
        {
            sum+=v[x];
        }
    }
    if this is called concurrently by multiple threads, there is 1 instance of x per thread, correct? each thread has it's own stack, right?

    i'm getting buffer overrun using code that was copied and pasted from a function that works fine.

  2. #2
    Registered User
    Join Date
    Apr 2008
    Posts
    395
    Maybe your vector is modified while some threads are using this function?

  3. #3
    The superhaterodyne twomers's Avatar
    Join Date
    Dec 2005
    Location
    Ireland
    Posts
    2,262
    It's easy to check if that's the case. Just pass the const std::vector<int> rather than the reference to the const std::vector<int>& and see if the same thing happens.
    It might also be with the variable sum that the problem is occurring. Just keep an eye on that too.

  4. #4
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839
    as usual (for me), i had confused the names of the loop index variables in copy/paste.

  5. #5
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,158
    What symptom are you observing that makes you think "buffer overrun?"

    Each thread has its own stack, but thread stacks are typically a lot smaller than the stack for the main thread, and they lack the ability to expand on demand like the main thread's stack can do.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  6. #6
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,607
    >> and they lack the ability to expand on demand like the main thread's stack can do
    What platform? I've not heard of this limitation on Windows or *nix.

    gg

  7. #7
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,158
    Quote Originally Posted by Codeplug View Post
    >> and they lack the ability to expand on demand like the main thread's stack can do
    What platform? I've not heard of this limitation on Windows or *nix.

    gg
    On Linux the main stack can continue to expand downward until it bumps into some other region. A thread has a stack with a size fixed at thread creation time (well, you can put it anywhere you want if you're willing to fiddle the stack pointer). This is just because "the stack" is something owned by the process, not any particular thread and the OS only manages one of them per process.

    You could simulate the auto-expanding stack with appropriate signal handlers, probably.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  8. #8
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,607
    >> ... "the stack" is something owned by the process, not any particular thread ...
    From my platform/OS agnostic point of view, when looking at the entire virtual memory address space of a process, there is no single "one stack to rule them all" type of concept. I like Linus's mental model of "context of execution" (COE). Using that model I would say that a single virtual memory address space can support multiple COE's, and that each COE has its own unique stack space. So under this model, "a stack" is associated with each COE.

    >> .. and the OS only manages one of them per process.
    I think "one per COE" is a more accurate statement for most platforms/OS's.

    On a particular architecture, there may something akin to a "stack segment" for which there is only one per virtual memory address space - but this is just an implementation detail to the OS. The typical conceptual model is "each thread of execution has its own stack space".

    >> You could simulate the auto-expanding stack with appropriate signal handlers, probably.
    Right - access to an mprotect()'d "guard page" triggers SIGSEGV - handler can then try to map in more contiguous memory, pushing the guard page down (or up). When there's no more contiguous VM, auto-expansion is done

    >> and they lack the ability to expand on demand
    I read "expand" in the wrong context originally.
    I was thinking "expand" = "paging in real memory as needed".
    Where I believe your intention was "expand" = "claiming contiguous VM pages in order to extend usable stack space".

    >> ... like the main thread's stack can do
    This is how Linux behaves, where the stack associated with the main() COE is the only stack with VM_GROWSDOWN. But that can only grow up to "ulimit -s" K, or getrlimit(RLIMIT_STACK). If you set this to "unlimited", then the main() COE stack is allowed to grow.

    This will be nice once it mainstream: http://gcc.gnu.org/wiki/SplitStacks

    gg

  9. #9
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,158
    This will be nice once it mainstream: SplitStacks - GCC Wiki
    That's neat. You can do some cool stuff with support from the tool chain.

    It would be interesting to put the return addresses on a completely different stack, and implement a software stack for local variables.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Simulating a pipe using threads and condition variables
    By Phoenix_Rebirth in forum C Programming
    Replies: 3
    Last Post: 07-23-2011, 04:40 PM
  2. Help with statistics level math within a function
    By nekrophiliak in forum C Programming
    Replies: 8
    Last Post: 04-03-2011, 02:10 AM
  3. bit level permutation function
    By zxcv in forum C Programming
    Replies: 2
    Last Post: 07-27-2008, 01:26 PM
  4. level files and variables
    By canine in forum Windows Programming
    Replies: 3
    Last Post: 09-25-2002, 10:00 PM
  5. Threads and global variables
    By Spark in forum C Programming
    Replies: 8
    Last Post: 05-29-2002, 02:08 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21