• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 215
  • Last Modified:

Does my thread need volatile variables?

I have a program that collects packets and stores info in a binary search tree. Every 5 minutes, I want to dump the tree to file and then repopulate with new packets. So, after I dump, I clear out the BST. My application uses libpthread. My BST is in global space, so that both threads can see it (one thread to collect, and one to dump to file).  When I don't clean up the tree, and just let it keep accumulating, the tree is fine, but when I delete and then start adding anew, the tree gets duplicates in it quite often. The function that clears the tree seems to work just fine. Could gcc 3.3.3 be pulling my leg with its optimzers and should I make my BST volatile?

This is my first program using threads and I'm not very good at debugging with threads at all.

going nuts,
      ryan
0
dignified
Asked:
dignified
3 Solutions
 
MysidiaCommented:
If the value of some local variable is to be modified by something external like that concurrently executing process, then yes,
that should be marked volatile

You also may need to enforce mutual exclusion when you are modifying the tree
(i.e. only one thread is modifying the tree at any given time, and no other thread
is trying to read the tree while a different one is removing from it or reading from it)

I don't know how you have it arranged, but it could be that for example, when one thread is trying
to empty the tree, another thread collects a new element and re-write parts of it, undoing some of the
remover thread's work



0
 
dignifiedAuthor Commented:
I am using mutexes also. I lock the tree before doing any operation on it, and still the odd behavior. Right now my variables are defined in global space, outside any functions. All references in functions are via pointers.
0
 
dignifiedAuthor Commented:
seems I found the bug, it was in my delete. A long story with something odd happening in my implementation. Thankfully, as far as I can tell right now, it does not involve a race condition. What is the best way to debug realtime threads anyways?
0
 
NovaDenizenCommented:
No joke, use many printfs.  It's pretty much impossible to reliably reproduce the timing that causes intermittent bugs in multithreaded programs, especially within a debugger.  Even using printfs can change the timing so that bugs stop happening (look up the "Heisenbug principle").  Closely follow a log and your understanding of your code will improve, which should help you sleuth out what is going wrong.

When writing multithreaded programs it's important to get your multithreaded basics right the first time and have a solid design that is both timing-proof and adequate for your needs.  
0
 
alericCommented:
No, volatile has to do with optimizations.

Suppose you have this code:

int* x = f();

int k = *x;
m = 3;
m += *x;

Then the compiler knows that no memory content was
changed by the 'm = 3' line (or whatever code is there),
and therefore that it is impossible that the value of *x
has changed: both 'x' as well and ANY memory did
not change.  It is therefore allowed to optimize this
code by storing the value of *x in a temporary (or
just reusing k):

int k = *x;
m = 3;
m += k;

Volatile now has the following meaning.  If you declare

int volatile* x = f();

Then the compiler is not allowed anymore to assume
that that value remains unchanged - even if it normally
would assume this because the code that it is generating
itself doesn't change the value.

If you use threads, and do not use locking, then it is true
that the value of *x could be changed by another thread.
But that is not what volatile is intended for.  You should
instead use proper locking.  For example:

lock_for_x();   // pseudo code
int k = *x;
m = 3;
m += *x;
unlock_for_x();  // pseudo code

If the other threads also use the same lock before
accessing whatever 'x' might point to (ie, some array
of ints with a fixed size) - then you garanteed that
indeed *x wasn't changed by another thread; and
the normal optimization is allowed: no volatile
needed.
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now