Is this concept thread safe?

[Red Squirrel]

I know about using mutexes and what not, but there are situations where using a bool on/off value is easier and more practical. Consider this scenario where thread A and B are in a loop:

(pseudo code)

global bool abc=false;
global array queue;

Thread A:
while(1)
{
if(!abc)
{
queue.AddData();
abc=true;
}

Do other stuff
}

Thread B:
while
{
if(abc)
{
queue.Flush();
abc=false;
}
}




This seems like it would be thread safe to me, but is there perhaps something I could be missing?

Basically thread A is the main program's thread, it buffers data to an array which is very fast, then thread B writes the data to disk, which takes longer (hence why it's in another thread so the program keeps running) but the part in thread A that writes won't write until thread B sets that bool to false.

Only thread A will ever set it to true and only thread B will set it to false.

[Codeplug]

Generally speaking, there is no guarantee of "visibility". Just because Thread B sets abc to false, there is no guarantee that Thread A will see it as false. When two threads access the same memory location, some sort of synchronization should be involved.

gg

[Arjay]

I know about using mutexes and what not, but there are situations where using a bool on/off value is easier and more practical.IMO, you would be better serve to just learn how to synchronize properly using the synchronization primitives. Sure there is an initial learning curve, but in the scheme of things, it's not that steep, and once you learn how, you can apply the same principles to more complex scenarios.

One of the best things ever for me was a friend explained the concept of RAII to me and turned me on to a lightweight set of classes that makes synchronization with a critical section very simple. Over the years I've improved on and extended these classes to include wrappers for a mutex and reader writer lock.

For your problem, the equivalent code using the RAII classes would be something like:

(pseudo code)
global LockableCS csLock;
global array queue;

Thread A:
while(1)
{
AutoLockT< LockableCS > lock( &csLock );
queue.AddData();

//Do other stuff
}

Thread B:
while
{
AutoLockT< LockableCS > lock( &csLock );
queue.Flush();
}

[Red Squirrel]

Here's another question for C#, dictionaries specificly.

Say I have a global accessible dictionary called Dict, would this be thread safe?

thread1 (loop):

lock(Dict)
{
//add/remove/change items from dictionary
}


thread2 (loop):

Dictionary Dict2 = null;
lock(Dict)
{
Dict2 = new Dictionary(Dict)
}

//loop through dict2




So basically I lock Dict, make a copy of it to a new dictionary, use that one to loop through, while the other one can be modified. Will I run into issues if the object references within Dict2 get modified while it gets looped through?

does lock even do what I think it does? I'm testing this without copying the array (locking entire loop) for testing only and still get crashes.

If I copy the array before I'm ok but think it's a time bomb thing, where if it happens to be copying at the same time as the other thread modifies it, it would probably crash.

[UnfitElf]

If you are using a simple type (bool etc) and the situation is correct you can use the volatile keyword. This is simplier than using mutexs etc (as you wanted) however, this cannot be used for every situtaion - there will be times, more often than not, when sync. objects are essential.

MSDN: Click Me! (http://msdn.microsoft.com/en-us/library/12a04hfd(VS.80).aspx)


volatile bool bRun = true;

void thread1(...)
{
while (bRun)
{
}
}

void OnBtnClick()
{
bRun = false;
}

[Codeplug]

The volatile keyword has nothing to do with multi-threaded (MT) programming. MSVC has added MT semantics to volatile starting with version 14 (VC++ 2005), but I don't recommend it's use because it will likely just degrade performance and limit the compilers ability to optimize the code.

It's much better to design out the need for synchronization (as much as possible), and use synchronization primitives proved by the OS or threading library when synchronization is needed.

gg