我应该总是在多线程编程中锁定全局数据吗，为什么或为什么不呢？

Question

I'm new to multi-thread programming(actually, i'm not a fresh man in multi-threading, but i always use global data for reading and writing thread, i think it makes my code ugly and slow, i'm eager to improve my skill)

and i'm now developing a forwarder server using c++, for simplify the question, we suppose there are only two threads, a receiving-thread and a sending-thread, and, the stupid design as usual, I have an global std::list for saving data :(

receiving-thread read raw data from server and wirte it into global std::list.

sending-thread read global std::list and send it to several clients.

i use pthread_mutex_lock to sync the global std::list.

the problem is that the performance of forward server is poor, global list locked when receiving-thread is wrting, but at that time, my sending-thread wanna read, so it must waiting, but i think this waiting is useless.

what should i do, i know that global is bad, but, without global, how can i sync these two threads?

i'll keep searching from SO and google.

any suggestions, guides, technology or books will be appreciated. thanks!

EDIT

1. for any suggestions, i wanna know why or why not, please give me the reason, thanks a lot.

Answer 1

Notes:

1. Please provide more complete examples: http://sscce.org/

Answers:

1. Yes, you should synchronize access to shared data.

   • NOTE: this makes assumptions about std::list implementation - which may or may not apply to your case - but since this assumptions is valid for some implementation you cannot assume your implementation must be thread safe without some explicit guarantee

   • Consider the snippet:

      std::list g_list; void thread1() { while( /*input ok*/ ) { /*read input*/ g_list.push_back( /*something*/ ); } } void thread2() { while( /*something*/ ) { /*pop from list*/ data x = g_list.front(); g_list.pop_front(); } } 

   • say for example list has 1 element in it
   • std::list::push_back() must do:
     • allocate space (many CPU instructions)
     • copy data into new space (many CPU instructions)
     • update previous element (if it exists) to point to new element
     • set std::list::_size
   • std::list::pop_front() must do:
     • free space
     • update next element to not have previous element
     • set std::list_size
   • Now say thread 1 calls push_back() - after checking that there is an element (check on size) - it continues to update this element - but right after this - before it gets a chance to update the element - thread 2 could be running pop_front - and be busy freeing the memory for the first element - which could result then in thread 1 causing a segmentation fault - or even memory corruption. Similarly updates to size could result in push_back winning over pop_front's update - and then you have size 2 when you only have 1 element.

2. Do not use pthread_* in C++ unless you really know what your doing - use std::thread (c++11) or boost::thread - or wrap pthread_* in a class by yourself - because if you don't consider exceptions you will end up with deadlocks

3. You cannot get past some form of synchronization in this specific example - but you could optimize synchronization

   1. Don't copy the data itself into and out of the std::list - copy a pointer to the data into and out of the list

   2. Only lock while your actually accessing the std::list - but don't make this mistake:

       { // lock size_t i = g_list.size(); // unlock if ( i ) { // lock // work with g_list ... // unlock } } 

4. A more appropriate pattern here would be a message queue - you can implement one with a mutex, a list and a condition variable. Here are some implementations you can look at:

   • http://pocoproject.org/docs/Poco.Notification.html
   • http://gnodebian.blogspot.com.es/2013/07/a-thread-safe-asynchronous-queue-in-c11.html
   • http://docs.wxwidgets.org/trunk/classwx_message_queue_3_01_t_01_4.html
   • google for more

5. There is also the option of atomic containers, look at:

   • http://calumgrant.net/atomic/ - not sure if this is backed by actual atomic storage (as opposed to just using synchronization behind an interface)
   • google for more

6. You could also go for an asynchronous approach with boost::asio - though your case should be quite fast if done right.