Partial Thread Synchronisation

Ahoy shipmates!

I'm using the Win32 API for this 'un.

Basically what I have is a main thread which creates a child thread. Now, the child thread won't get it's parameters because the creating function returns before the thread gets started.

Oh, by the way, I'm not supposed to be using any special libraries or anything for this project.

[quote name='Chicktopus' timestamp='1303247147' post='4800511']
Oh, by the way, I'm not supposed to be using any special libraries or anything for this project.

Well, I've tried initialising each variable using the the new operator. So far so good. I'm having a little trouble deleting them, though. Getting a few Debug Assertions. I can probably fix that by myself, though.

One thing before I continue any further: The data I'm passing in to this thread is all constantly being updated by the main thread. I need these changes to change the data in this child thread, too. Is that going to happen if I use new? I guess the data in the main thread should update the exact same variables I'm passing to the thread, so I'm updating the data at the address, which means I then just worry about deleting them all in the main thread too?


ColParams g_colParams
//Window.cpp
void Window::OnCreate()
{
// ...
g_collision.Start(g_colParams);
//<----------- if I update here, it's change it in the child thread
}//OnCreate
void Window::OnDisplay()
{
planeCount = 200; //<---------- Yet if I update it say here, it'll only change in this main thread
}//OnDisplay



void Collision::ApplyEffect(void* p_params)
{
ColParams* m_temp = (ColParams*)p_params;
ColParams m_params = *m_temp;

const unsigned int p_planeCount = *m_temp->planeCount;
const unsigned int p_sphereCount = *m_temp->sphereCount;
float p_time = *m_temp->time;
Plane* p_plane = m_temp->planes;
Sphere* p_sphereArr = m_temp->spheres;
delete m_temp;

...

while(1) //Just run forever for now, until I figure out a better way to stop the thread
{
m_planeCount = m_planeCount; //Check to see if anything's been updated
...
}
}//ApplyEffect
[/quote]

What is this while loop supposed to be doing? It's not checking anything. It's also not clear to me which thread is supposed to be running which part of your code.

If I were you, I'd forget about Windows and Collision systems and concentrate on getting the basics right w.r.t to synchronization. Once that's nailed, move back to your real code.

Wrapping up Red Ant's suggestion in to something reusable, we have:


// Uncompiled/untested

#include <windows.h>
#include <process.h>

#include <cassert>
#include <memory>

namespace detail
{
// implementation detail of create_thread
template<typename Callable>
unsigned thread_body(void *callable)
{
assert(callable);
std::auto_ptr<Callable> functoid(static_cast<Callable*>(callable));
(*functoid)();
return 0;
}
}

// Create a thread (whose HANDLE is returned), that runs a *copy* of functoid,
// which should be a callable object or pointer-to-function.
// Use join_thread() to wait for termination.
template<typename Callable>
HANDLE create_thread(const Callable &functoid)
{
Callable *copy = new Callable(functoid);
uintptr_t h = _beginthreadex(0, 0, &detail::thread_body<Callable>, copy, 0, 0);

if (h == 0)
{
delete copy;
return 0;
}

return reinterpret_cast<HANDLE>(h);
}

// Wait for the specified thread to finish.
// It is assumed the thread was created with create_thread.
bool join_thread(HANDLE thread)
{
assert(thread);
bool ok = WaitForSingleObject(thread, INFINITE) == WAIT_OBJECT_0;
if (ok) CloseHandle(thread);
return ok;
}


Given that, we can do things like


struct MyThread
{
MyThread(int *a, const std::string &b) : a(a), b(b) { }
void operator() () { /* thread body goes here, can use 'a' and 'b' */

int *a;
std::string b;
};

int main()
{
// The thread we create here gets its own copy of the MyThread object
// we create, so there aren't any races. However, given that MyThread::a is a pointer,
// the thread we create now effectively has access to our local variable 'a':
int a = 42;
HANDLE h = create_thread(MyThread(&a, "hello"));


if (!h) return 1;
// ...

join_thread(h);
return 0;
}


What you're describing is a good candidate for a task-driven approach, rather than creating a fixed number of threads for specific things. Have you explored things like Microsoft's Parallel Patterns Library?

EDIT: By the way, you can't (reliably) have threads communicate with each other like that:


while ( !g_terminated )
{
}


Any and all concurrent access to shared data must use some form of sychronization, or else the results are undefined. Each time you want to inspect or alter the value of your g_terminated variable, you must first acquire some kind of lock (read up on critical sections ... use the msdn online documentation). Otherwise all kinds of weird things can happen, such as one thread changing the value of g_terminated but the other thread never seeing the change.

Simple reads and writes to properly-aligned 32-bit variables are atomic operations. In other words, you will not end up with only one portion of the variable updated; all bits are updated in an atomic fashion. However, access is not guaranteed to be synchronized. If two threads are reading and writing from the same variable, you cannot determine if one thread will perform its read operation before the other performs its write operation.
[/quote]

Busy-polling a variable might be a bad idea for other reasons, like hogging up excessive CPU resources.

[quote name='Red Ant' timestamp='1303248265' post='4800520']
EDIT: By the way, you can't (reliably) have threads communicate with each other like that:


while ( !g_terminated )
{
}


Any and all concurrent access to shared data must use some form of sychronization, or else the results are undefined. Each time you want to inspect or alter the value of your g_terminated variable, you must first acquire some kind of lock (read up on critical sections ... use the msdn online documentation). Otherwise all kinds of weird things can happen, such as one thread changing the value of g_terminated but the other thread never seeing the change.

Ok, I do believe I have fixed it all. Critical sections were't working for me, but mutexes worked like a charm. Problem resolved!

Are you aware of the memory visibility issues that doing so could entail? For instance, the OS might decide that thread A should move g_terminated to some kind of cache and then access that for increased speed. Meanwhile, thread B (whose version of g_terminated resides in RAM) modifies g_terminated. However, it is not aware that thread A has moved its version to a cache, so thread A never gets to see the changed value of g_terminated.

It's not guaranteed which order the caches will be notified if you change a variable like in the above example, but they'll all know it eventually. If thread A is just waiting for thread B to set a bool to true, it will get the new value eventually when the cache is updated.

Again, best to just do the right thing and wrap your shared data up in a critical-section/mutex to avoid these problems (unless you've got a good reason not to).

if you can't afford wait times (mutexes and timers cause them), you can use round-robins so that only one thread is doing work on something at a time

thread a:

if (a == 0)
do work
a = 1;


thread b:

if (a == 1)
do work unless too much time is spent
if (the work is completely done) a == 0;