Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #3714 > unrolled thread

About C++ and real-time OSs...

Back to article view | Back to comp.programming.threads

Contents

  About C++ and real-time OSs... Ramine <toto1@toto1.net> - 2017-04-02 17:13 -0400
    Re: About C++ and real-time OSs... Ramine <toto1@toto1.net> - 2017-04-02 17:31 -0400
      Re: About C++ and real-time OSs... Ramine <toto1@toto1.net> - 2017-04-02 18:09 -0400

#3714 — About C++ and real-time OSs...

Hello,


I have been working on a queue with a condition variable, but
i have noticed that a condition variable does not work
correctly, because the threads must be waiting to be able
to be signaled, if they are not waiting the signal will be lost,
so the way that many are using a condition variable with
a FIFO queue is not correct, they are for example using
this logic on the consumer side:

  while(the_queue.empty())
         {
             the_condition_variable.wait(lock);
         }


and this is not correct, because if the_queue_empty() is true ,
and the last producer thread signals before the consumer
thread is waiting for the condition variable , so this will deadlock,
so i have avoided condition variables and i have designed and 
implemented an efficient real-time and thread-safe and bounded FIFO 
Queue and Stack an i am actually finishing them and they are working 
well, and i will soon posted them on internet.



Thank you,
Amine Moulay Ramdane.

[toc] | [next] | [standalone]

#3715

On 4/2/2017 5:13 PM, Ramine wrote:
> Hello,
>
>
> I have been working on a queue with a condition variable, but
> i have noticed that a condition variable does not work
> correctly, because the threads must be waiting to be able
> to be signaled, if they are not waiting the signal will be lost,
> so the way that many are using a condition variable with
> a FIFO queue is not correct, they are for example using
> this logic on the consumer side:
>
>  while(the_queue.empty())
>         {
>             the_condition_variable.wait(lock);
>         }
>
>
> and this is not correct, because if the_queue_empty() is true ,
> and the last producer thread signals before the consumer
> thread is waiting for the condition variable , so this will deadlock,
> so i have avoided condition variables and i have designed and
> implemented an efficient real-time and thread-safe and bounded FIFO
> Queue and Stack an i am actually finishing them and they are working
> well, and i will soon posted them on internet.
>
>
>
> Thank you,
> Amine Moulay Ramdane.
>

To solve this problem with a condition variable , of course
the signaling of the condition variable must be inside the
critical section of the producers.

But there is still a problem, it is a problem with the latency
in real-time systems, if you use only one pthreads mutex
for the producer side and the consumer side , the latency will get much 
bigger, because the consumers have to wait for the producers in a FIFO 
priority manner, so you have to wrap the producer side inside another 
pthreads mutex to lower the latency for the condition variable
case, or you have to use smartly a pthreads semaphore.


Thank you,
Amine Moulay Ramdane.

[toc] | [prev] | [next] | [standalone]

#3716

On 4/2/2017 5:31 PM, Ramine wrote:
> On 4/2/2017 5:13 PM, Ramine wrote:
>> Hello,
>>
>>
>> I have been working on a queue with a condition variable, but
>> i have noticed that a condition variable does not work
>> correctly, because the threads must be waiting to be able
>> to be signaled, if they are not waiting the signal will be lost,
>> so the way that many are using a condition variable with
>> a FIFO queue is not correct, they are for example using
>> this logic on the consumer side:
>>
>>  while(the_queue.empty())
>>         {
>>             the_condition_variable.wait(lock);
>>         }
>>
>>
>> and this is not correct, because if the_queue_empty() is true ,
>> and the last producer thread signals before the consumer
>> thread is waiting for the condition variable , so this will deadlock,
>> so i have avoided condition variables and i have designed and
>> implemented an efficient real-time and thread-safe and bounded FIFO
>> Queue and Stack an i am actually finishing them and they are working
>> well, and i will soon posted them on internet.
>>
>>
>>
>> Thank you,
>> Amine Moulay Ramdane.
>>
>
> To solve this problem with a condition variable , of course
> the signaling of the condition variable must be inside the
> critical section of the producers.
>
> But there is still a problem, it is a problem with the latency
> in real-time systems, if you use only one pthreads mutex
> for the producer side and the consumer side , the latency will get much
> bigger, because the consumers have to wait for the producers in a FIFO
> priority manner, so you have to wrap the producer side inside another
> pthreads mutex to lower the latency for the condition variable
> case, or you have to use smartly a pthreads semaphore.
>
>
> Thank you,
> Amine Moulay Ramdane.
>
>
>
>


The problem with the latency on real-time systems, can be
solved with the condition variable by using two pthreads mutexes,
one for the consumer side, and one for the producer side,
not just one as is using many.


Thank you,
Amine Moulay Ramdane.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web