| Doug Mika <dougmmika@gmail.com>: Jul 30 02:59PM -0700 Let me first illustrate the simple problem: If I have a stack data structure accessed by two threads and the following code that runs on both threads: if(!stack.empty()){ .. stack.pop(); .. } then I may encounter a problem if thread A executes pop() after thread B passes the if statement. That is, there is a chance that if I have one element on my stack, that both threads may execute pop() on it. The simple solution that comes to my mind is to wrap this entire block of code: if(!stack.empty()){ .. stack.pop(); .. } in a mutex to ensure that only one thread executes it at a time. Is there another neat/quick way to achieve what I'm trying to do? |
| Victor Bazarov <v.bazarov@comcast.invalid>: Jul 30 06:41PM -0400 On 7/30/2015 5:59 PM, Doug Mika wrote: > Let me first illustrate the simple problem: > If I have a stack data structure accessed by two threads and the following code that runs on both threads: > } > then I may encounter a problem if thread A executes pop() after > thread B passes the if statement. That is, there is a chance that if I have one element on my stack, that both threads may execute pop() on it. > The simple solution that comes to my mind is to wrap this entire > block of code: > } > in a mutex to ensure that only one thread executes it at a time. Is > there another neat/quick way to achieve what I'm trying to do? What do the dots designate in your example? Some other processing? Does it only happen if the stack is not empty? If you make this processing exclusive (with a mutex or critical section or a semaphore), in other words if you make it synchronous, will it be a performance bottleneck? If not, it's probably OK to lock the whole thing. What book are you reading on threads? What do they say about such situations? BTW, have you found 'comp.programming.threads' newsgroup yet? V -- I do not respond to top-posted replies, please don't ask |
| Ian Collins <ian-news@hotmail.com>: Jul 31 10:42AM +1200 Doug Mika wrote: > if(!stack.empty()){ .. stack.pop(); .. } > in a mutex to ensure that only one thread executes it at a time. Is > there another neat/quick way to achieve what I'm trying to do? Please wrap your lines! Use a condition variable with !stack.empty() as the condition. -- Ian Collins |
| Christopher Pisz <nospam@notanaddress.com>: Jul 30 06:43PM -0500 On 7/30/2015 4:59 PM, Doug Mika wrote: > .. > } > in a mutex to ensure that only one thread executes it at a time. Is there another neat/quick way to achieve what I'm trying to do? If I have some data structure that I am going to share between thread, I prefer to make my own class, write the same interface, make the original data structure a private member, and then have the class I wrote control the data and the mutex. Incomplete example: template <T> class ConcurrentStack { public: void push(const T & value) { m_mutex.lock(); m_stack.push(value); m_mutex.unlock(); } T pop() { m_mutex.lock(); T value(m_stack.pop()); m_mutex.unlock(); return value; } private: std::stack<T> m_stack; std::mutex m_mutex; }; basic idea...I'm sure you can make it more efficient and take care of the nuances from there. I keep a concurrent library in my common code for such things. I like my container to own its own mutex rather than someone else and especially rather than a whole bunch of people trying to lock and unlock it. This way, no one need worry about the fact that there is a mutex, threads must simply be aware that they have to wait via the documentation. -- I have chosen to troll filter/ignore all subthreads containing the words: "Rick C. Hodgins", "Flibble", and "Islam" So, I won't be able to see or respond to any such messages --- |
| Christopher Pisz <nospam@notanaddress.com>: Jul 30 06:33PM -0500 Is there a way to set the delimeter for an istringstream when using the '>> operator'? I prefer to not use getline if possible. -- I have chosen to troll filter/ignore all subthreads containing the words: "Rick C. Hodgins", "Flibble", and "Islam" So, I won't be able to see or respond to any such messages --- |
| "Öö Tiib" <ootiib@hot.ee>: Jul 30 12:23AM -0700 On Wednesday, 29 July 2015 02:18:33 UTC+3, Alf P. Steinbach wrote: > nodes. At the coding/implementation level it's inappropriate because > it's more verbose and hence less maintainable code, and also (but > secondary) just needless memory and possibly execution time overhead. There may be cases where such design makes best sense and when it makes sense then it usually simplifies coding as well. I can think of two: 1) Case when element is most logical owner of next element. Singly linked list is technically subcase of tree. Sort of one-branched tree. If trunk interacts with its branch then a reference makes sense. If trunk owns the branch then smart pointer makes sense as that reference. 2) Case when neither elements nor the list own elements. Elements are owned by something outside but sometimes form such temporary lists. Intrusive list may perform better and make better sense than list of pointers. Non-owning 'std::unique_ptr' may be used there as link between elements to signal the "something outside" that element has left such list. Performance-wise there is very little difference between 'unique_ptr' and raw ... it is 'shared_ptr' that is fat. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment