I'm new to building apps in MFC/VS/VC++.
I've spent a great deal of time reading SO and it's disconcerting as they assert the MSDN documentation is flat-out wrong as to the (lack of) thread-safety of Microsoft constructs including volatile variables and tools such as InterlockedIncrement. I have an application I am developing where one thread generates a list of tasks to be performed, storing these in a structure, while other threads poll to perform these tasks as they become prompt and appropriate. The logic of the code would appear naively to preclude race conditions, as functions are called which change the global variables/structure before other functions are called which use them. Of course, the compiler (VS2003 for me) can compile in a way where the calling thread may not re-check the value of the global variable each time, so it may not see the updated values. The function "InterlockedIncrement" was built for applications as mine, and I use it to increment and decrement the count of the number of tasks in the list, so each worker thread knows how many tasks are in the list to be scanned. But the tasks are relatively complex structures being modified by the task-building thread, and are subject to "invalidation" (and disaster for me) if a worker thread were to read one only partly completed.
Which simple strategies are best for the relatively simple application where only one thread is making changes to shared structures while many other threads read these?
Submit an article or tip