-
June 7th, 2013, 08:33 AM
#1
MultiThread Race Condition
MultiThread Race Condition
I am creating an application that is multithreaded and all the threads are accessing the same shared memory. The data coming into the memory should be processed in sequential order. Like if 1,2,3,4,5 comes in the memory then it should be processed in same order.
I have used critical section around my memory, but I still get into a race condition where data is not grabbed by the thread in sequential order.
Am I missing anything else to prevent threads from race condition?
Thanks.
ACpp
-
June 7th, 2013, 08:39 AM
#2
Re: MultiThread Race Condition
Please post your code so we can have a look at what you are doing (use code tags - Go Advanced, select code, click '#') and can provide helpful comments and advice.
Like if 1,2,3,4,5 comes in the memory then it should be processed in same order.
Comes into memory how? from where? One of the points about multi-threading is that several threads can execute simultaneously. If you need to process events sequentially why multi-threaded?
All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!
C++23 Compiler: Microsoft VS2022 (17.6.5)
-
June 7th, 2013, 08:46 AM
#3
Re: MultiThread Race Condition
Thanks.
The data in the shared memory comes from a different thread.
Thread1 -----> [SHARED MEMORY] ----> data taken out by multiple threads.
Why multiple threads? Because data is taken out by these threads and applied to some processing/implementation, before a thread can go back and grab next data.
When I use 1 thread the chances of memory getting full from data coming from Thread1 is very high.
I can post the code, but there are many library functions associated with it. Let me try modifying and I can post the code.
-
June 7th, 2013, 09:02 AM
#4
Re: MultiThread Race Condition
Sounds like you have a single producer, multiple consumers design. Best way to implement that is to write a queue that takes care of all the synchronization. Then your producer and consumer threads can be written lock-free.
Cheers, D Drmmr
Please put [code][/code] tags around your code to preserve indentation and make it more readable.
As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky
-
June 7th, 2013, 09:45 AM
#5
Re: MultiThread Race Condition
Thank You. Any example that I can take a look at ?
Thank You.
A
-
June 7th, 2013, 02:27 PM
#6
Re: MultiThread Race Condition
I tried to modify my code to post it here, but I think it will be simple if I write it down and explain what I have implemented.
There is one source input - Single thread to feed DATA into the shared memory. The shared memory is a Queue.
Created 2 thread to access the shared memory DATA.
But every data piece coming out of the shared memory might not take same time for the processing. So the data the threads go out of sync
For example:
Output: Thread1 and Thread2
DATA: 1,2,3,4,5,6,7,8,9,10
If 1 takes longer time to process compared to 2 (because of its data content), then Thread2 will be done earlier
and will jump on data number 3 and might even process 3 before 1 is even completed.
Thread1 - Processing 1
Thread2 - Processed 2
Thread2 - Processed 3
Thread2 - Processing 4
Thread1 - Processed 1
.....
...
.. so on.
Is there a way to make sure that thread2 waits and process them in sequential until thread1 data processing is completed ?? Please let me know if there is any confusion. Thank You in advance.
-
June 7th, 2013, 02:28 PM
#7
Re: MultiThread Race Condition
Originally Posted by AdvanceCPP
Thank You. Any example that I can take a look at ?
Did you try searching the internet?
Originally Posted by AdvanceCPP
Is there a way to make sure that thread2 waits and process them in sequential until thread1 data processing is completed ?? Please let me know if there is any confusion. Thank You in advance.
There are plenty of ways. An elegant approach using futures is described in the following article: Waiting for One-Off Events with Futures.
Last edited by D_Drmmr; June 7th, 2013 at 02:33 PM.
Cheers, D Drmmr
Please put [code][/code] tags around your code to preserve indentation and make it more readable.
As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky
-
June 7th, 2013, 02:42 PM
#8
Re: MultiThread Race Condition
I tried to modify my code to post it here, but I think it will be simple if I write it down and explain what I have implemented.
But we can't guess what exactly your code is doing! Yes, you can get one thread to wait for another. One way is to use event signalling.Thread1 raises signal1 at the end of processing and waits for signal2 to be raised before continuing. Thread2 raises signal2 at the end of processing and waits for signal1 to be raised before continuing. This is simplistic and care needs to be undertaken to make sure deadlock condition is not reached (thread1 waiting for signal2 and thread2 waiting for signal1).
Look at Event Objects and Synchronization Functions in Microsoft help.
All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!
C++23 Compiler: Microsoft VS2022 (17.6.5)
-
June 7th, 2013, 04:53 PM
#9
Re: MultiThread Race Condition
>> Is there a way to make sure that thread2 waits and process them in sequential until thread1 data processing is completed ?
Threads allow you to do multiple things at the same time. If "2" can't be processed until "1" is complete, then threading is of no use.
gg
-
June 10th, 2013, 04:11 AM
#10
Re: MultiThread Race Condition
Originally Posted by D_Drmmr
Sounds like you have a single producer, multiple consumers design. Best way to implement that is to write a queue that takes care of all the synchronization. Then your producer and consumer threads can be written lock-free.
Do you happen to have a link to this lock-free queue implementation ?
I know how to do a lock free single linked list, which you could use for a multi(or single)-producer/single-consumer queue like behaviour.
But true lock free queue behaviour on multi consumer has eluded me. Only resources I could find so far do actually have a lock on the consumer side.
-
June 10th, 2013, 08:29 AM
#11
Re: MultiThread Race Condition
Originally Posted by OReubens
Do you happen to have a link to this lock-free queue implementation ?
My use of the term "lock-free" was inaccurate. I just meant that you don't need to explicitly lock in the producer/consumer code, not that you don't need a mutex or CS for the implementation of the queue.
For a true lock-free queue, look e.g. at http://blogs.msdn.com/b/nativeconcur...in-vs2010.aspx.
Cheers, D Drmmr
Please put [code][/code] tags around your code to preserve indentation and make it more readable.
As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky
-
June 11th, 2013, 03:07 AM
#12
Re: MultiThread Race Condition
Originally Posted by AdvanceCPP
Thread1 -----> [SHARED MEMORY] ----> data taken out by multiple threads.
Why multiple threads? Because data is taken out by these threads and applied to some processing/implementation, before a thread can go back and grab next data.
When I use 1 thread the chances of memory getting full from data coming from Thread1 is very high.
Your requirement of sequential processing contradicts to multi-threading. Period. And I'm not the first person in this thread who told you this. You need to revise this sequential thing. Or give up.
In case your writer (Thread1) is able to flood the shared memory, you have to change approach. Like introducing something similar to flow control concept that widely used in hardware interfaces and multimedia streaming: in case writer side performance exceeds reader's abilities, the reader notifies writer back to stop writing until the buffered data becomes fully processed. Otherwise excessive data has to be dropped to prevent choking the downstream mechanisms.
Best regards,
Igor
-
June 13th, 2013, 06:43 AM
#13
Re: MultiThread Race Condition
Originally Posted by AdvanceCPP
Is there a way to make sure that thread2 waits and process them in sequential until thread1 data processing is completed ?? Please let me know if there is any confusion. Thank You in advance.
-> Assumption is that data2 can be processed before data1 processing is completed.
If this is not the case, then multiple processing threads aren't going to help you at all, you then have single processor thread that handles things in order.
If processing can be done out of order, but you need ordering at the output, then the solution is simple. You sort the output. Or if you need this more dynamically you tack on a backprocessor that takes the processed packages from the worker threads, stores them in a container and doesn't release packages until it can reassure ordering.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|