Simple threading question

[Kevin Cramer]

I know threading has been asked a lot here, especially regarding the use of global variables. But I want to be clear on something cause I am seeing some funky behavior.

I have some master data tables that are created before any threading is run. These tables are large and I do not want each thread to get its own copy. So these tables are global variables. The threads need to read the data in the tables, but do not need to update them in anyway.

So the question is: "Are there any contention issues with threads when just *reading* data from global variables but not updating them?"

Thanks,
kevin

[Mike Doty]

No problem reading the data if it cant' change while reading.

[Jeff Blakeney]

As long as absolutely nothing ever changes those tables, then there are no problems. If there is even one thread that can update those tables, then you could potentially run into problems with large data types (ie. quads or strings) being only partly updated when another thread reads the data.

[Kevin Cramer]

Threading and Globals

Thanks for the replies...

FYI...there are definitely no updates of these tables...and my threading is now working fine. Its nice to see 16 threads cranking away on 8 cores.

Now give me 64 bits of memory space and I could work wonders

Cheers,
Kevin

[Eddy Van Esch]

If there is even one thread that can update those tables, then you could potentially run into problems ....

But then you can use Critical Sections to solve that problem.

Kind regards

[Kevin Cramer]

Thanks for the replies. Here is a different question on this topic. Suppose I have the same global array that I am working with in threads. The array is of fixed size as far as elements and the size of the elements.

Each thread will be updating this array, but the each thread will only be updating a section of the array that will never be updated by another thread. Is this OK with threading rules or will it cause contention even though the threads should never be accessing the same memory space?

[Jeff Blakeney]

As long as each thread sticks to its own section of the global array things should be fine. Even an array of dynamic strings should be okay as a string array is just an array of string pointers if I recall correctly.

However, you could just create an array in each thread. If the threads aren't going to read or write to the other sections of a global array, then you could just declare an array in each thread function (or just the one with a if you are using the same thread function multiple times). If you need to get access to that data when the thread is done so that you can do something with all of the separate arrays, there are ways of sending data back to your main thread that can be used. I'm no expert on them so I'll leave that for others to comment on if you are interested in pursuing that method.

[Shannon David Larratt]

If there is any possibility of a collision, you can also make each little section that writes to the array a critical section, which will cause it to be executed in full before control gets passed to any of the other threads...

[Michael Mattias]

Yo, guys, the question re "load only" was answered by Mr. Doty in post #2: If these tables are loaded once and never updated, there is no problem. None. There are no 'collision' issues. There's no need to restrict access to "portions" of the table.

If you want to update the tables, that's a horse of a different color.

While restricting access to 'portions' of the array for update purposes would work, the critical section is the synchronization object of choice.

[Conrad Hoffman]

Well, I never thought I'd see the day- Michael has officially approved the use of a global variable!

I've been trying to rid myself of them for ages, but for every program there seems to be a case where using a global is just easier and less confusing, and the OPs case seems to be one of them.

CH

[Michael Mattias]

Well, I never thought I'd see the day- Michael has officially approved the use of a global variable!

Heck I use 'em myself.

What I am against is the unnecessary use of same, or uses which will require code changes should you want to update your program to A) be made re-entrant; B) move some procedures to a different code module; or C) reuse specific procedures in another application . An over-reliance on GLOBAL variables makes both these tasks far more work than necessary.

That is, while GLOBALs can be convenient today, there's a good chance you'll be paying for that decision tomorrow.