views:

100

answers:

5

Hi All

I need to access(only read) the data in std::list from one or more threads running in my application.

This list will be created only once at time of booting an application and after all this list will be reading

from muliple threads...say I will be doing this

for (std::list <iterator>iii=list->begin();ii!=list->end();ii++)

which read the list from muliple threads.

now my question is will it create any access violation problem if i didn't synchronize the access to list?

I ran the application without any synchronization prirmitives. i didn't face nay problem. but since I am doubt about this I would like to confirm it .

As per my understanding even in mutithreading application only one thread executes at run time by OS. since I am not updating list from muliple threads and all the threads are reading the list it may not necessary to give exclusive access to list..is it correct?

please put me in correct way if I am doing wrong

+5  A: 

You are right, if you are doing just read operation on the list object without any write operations you wont face any problems. However, note that in case processors with multiple cores it is possible multiple threads run at the same time.

Naveen
In fact, it's one of the most important approaches to design fast, multi threaded code: fill a data-structure in one thread and make it readonly before publishing it to other threads. No need for locks, and no danger of deadlocks either.
Sjoerd
Thanks for the response.
Sukumar
+2  A: 

If all you are doing is reading the list, you don't need to lock it. However, presumably the data in the list got put there somehow, so unless your reading threads start after the list is populated, and the list contents never change, you will need a lock for both the readers and the writer(s).

anon
My reading threads strats after the list is populated and the list content never change..
Sukumar
@Sukumar: If you can guarantee that you won't have a race condition or some other conflict, then you don't need locks.
0A0D
+1  A: 

In addition to the previously said - it would be a good practice to pass the list object around as reference-to-const. That would avoids any accidental modifications, caused by future code changes.

Mart Oruaas
A: 

If runtime is more important than init time, consider using std::vector since the data will not change after final init.

baardk
A: 

from muliple threads...say I will be doing this which read the list from muliple threads. now my question is will it create any access violation problem if i didn't synchronize the access to list?

That type of constructions wouldn't not. Though looking forward, you might want to check readers/writer locks.

As per my understanding even in mutithreading application only one thread executes at run time by OS.

If you have multiple threads and OS has access to multiple CPUs/cores, threads would be executed simultaneously. That's called preemptive multitasking and multi-threading is the way for applications to access the multiple CPUs/cores.

And even on single CPU/core, OS might decide to preempt one thread to give another thread chance to run. Good OS tries to make sure that all threads in a program which can be ran will receive nearly equal time to run.

since I am not updating list from multiple threads and all the threads are reading the list it may not necessary to give exclusive access to list..is it correct?

If any of the threads sometimes updates the list, then you need locking.

Otherwise, if for example the list is populated in main threads, before the worker threads are started, then it is perfectly to omit the locking. And that is only scenario where I would use no locking. If the list is populated by another thread, when there are already many threads running, I would already add locking: multi-threading issues inside of STL containers are hell to debug, while reader/writer lock has negligible overhead.

Dummy00001