Race condition: getting multiple threads to cooperate

[azteched]

Ahh it seems that I can use InitialiseCriticalSection(), EnterCriticalSection(), LeaveCriticalSection() and DeleteCriticalSection(). This seems to be aimed at threads of the same process as opposed to mutex which is between threads on different processes.

Yep. (N.b. I use the term mutex to refer to CRIT_SECT because it's in line with pthreads terminology).

To be able for all the threads to access the threadBlocker it seems I must make it global, or either create a new object in which to encapsulate everything that get passed to the new threads. Or is it possible to pass more than one object to a new thread?

You could pass a pointer to a struct containing all the data required for the thread, e.g.

struct thread_stuff {
char *something;
int something_else;
CRITICAL_SECTION* thread_lock;
};

That said, I'd wrap CRIT_SECT up in a C++ object.
Scoped RAII locking also helps, especially when you have multiple return paths from a function where you locked your mutex.

Also:

Your "while some cond" loops should probably be turned into condition variable waits.

Presumably you're setting your "some cond" from one thread and then testing from another to see if there's work available, or whatever - you should probably use a condition variable & mutex to wait on the condition, rather than using sleep.

Side note: boost provides an OO mutex, condition variable, and scoped RAII lock.

[FlyingDutchMan]

Thanks for that. Good to know I wasn't going to far off track.

The sleep is so it can update itself every 5 mins or so (connect to other computers with the same setup). According the borland C help I have here it suspends the threads execution until the time is up. The intended method of exiting the program is through a network connection so the global is there just waiting for that. I'll probably stick that global in the object that gets passed to the threads so that its no longer global (I hate globals!). You are right though - there will be an unseemly wait of upto 5 mins before exiting the main loop. I will have to get that one tieded up.

The masterServerThread uses the listen() so that doesn't use anything until a connection comes in.

The listenServerThread loop is waiting on data from the network so
that should also be a non resource hogging wait, and the threads survival would be lucky to exceed 1 or 2 seconds (hence the unlikelyhood of race condidtions).

Scoped RAII locking also helps, especially when you have multiple return paths from a function where you locked your mutex.

And some pureists say that there should only be one entry and exit point in functions... which would solve that problem, but I can't be assed being a pureist. I'll just settle for stable - I don't think it'll be much of an issue to put a LeaveCriticalSection() before every return.

[adrianxw]

A critical section and a mutex are different objects on a Windows system. A critical section can only used by the threads of a single process. It is very fast and has a low overhead. A named mutex can be used across process boundaries to synchronise threads in several different programs.

I have a very basic MT tutorial starting here but you've got the general idea now anyway.

[FlyingDutchMan]

A critical section and a mutex are different objects on a Windows system. A critical section can only used by the threads of a single process. It is very fast and has a low overhead. A named mutex can be used across process boundaries to synchronise threads in several different programs.

I have a very basic MT tutorial starting here but you've got the general idea now anyway.

Thanks for that... I got the tutorial working perfectly. I'm using the WaitForSingleObject() in the main program loop and after the time out iit can do the client stuff, or if the server thread dies, it will exit straight away. Much better.