<p dir="ltr"><br>
On Jul 4, 2014 9:19 AM, smc smc <smc101979@gmail.com> wrote:<br>
><br>
> Hi Joel, I have not set special attributes on the pthreads. I set NULL on second parameter of pthread_create(). However, I did some experiments changing the scheduling policy and priorities, but the result was similar.<br>
><br>
 <br>
With NULL as the attributes, they are different on the two systems. </p>
<p dir="ltr">Try to produce a small example which shows this behavior and the community can help.</p>
<p dir="ltr">><br>
><br>
> 2014-07-04 15:07 GMT+01:00 Joel Sherrill <Joel.Sherrill@oarcorp.com>:<br>
>><br>
>><br>
>> On Jul 4, 2014 8:33 AM, smc smc <smc101979@gmail.com> wrote:<br>
>> ><br>
>> > Hi, thanks all for your suggestions.<br>
>> ><br>
>> > @Sebastian: the bsp is MPPA.<br>
>> > @Gedare: I cannot send the full code for debugging, because part of it uses an proprietary API :/ About your comment, I commit a mistake transcribing the code, it is not an assignment operator, it must be '=='.<br>
>>   <br>
>> You should be able to produce a generic version that bus smaller and reproduces the problem.<br>
>><br>
>> You did not answer if you have default attributes on the pthreads and other objects. They are undefined by POSIX and differ between RTEMS and Linux.<br>
>><br>
>> Also a thread spinning in a loop at the highest priority in RTEMS will do that forever. My impression is that is what your init thread is doing.<br>
>><br>
>> > Anyway, I am trying to use condition variables, despite of loosing some of performance.<br>
>> ><br>
>> > Regards.<br>
>> ><br>
>> ><br>
>> ><br>
>> > 2014-07-03 2:37 GMT+01:00 Gedare Bloom <gedare@rtems.org>:<br>
>> >><br>
>> >>  I'll make one note below, but you should submit the entire<br>
>> >> self-contained example that shows the incorrect behavior if you want<br>
>> >> debugging help.<br>
>> >><br>
>> >> On Wed, Jul 2, 2014 at 6:23 AM, smc smc <smc101979@gmail.com> wrote:<br>
>> >> > Hi, I am new in RTEMS. I can't understand why the following threaded<br>
>> >> > application is not running on RTEMS as expected. Basically, it creates two<br>
>> >> > pthreads. One fills a buffer and the other one get an slice and submit it to<br>
>> >> > a cluster for processing (typical producer-consumer problem), something<br>
>> >> > like:<br>
>> >> ><br>
>> >> > void thread1()<br>
>> >> > {<br>
>> >> >   while(1)<br>
>> >> >   {<br>
>> >> >     for (i=0; i < size;i++)<br>
>> >> >     {<br>
>> >> >       if (buffer[i].st == -1)<br>
>> >> >       {<br>
>> >> >         pthread_mutex_lock(&mutex);<br>
>> >> >           genData(buffer[i]);<br>
>> >> >           buffer[i].st=0;            // ready to be consumed<br>
>> >> >         pthread_mutex_unlock(&mutex);<br>
>> >> >       }<br>
>> >> >     }<br>
>> >> >   }<br>
>> >> > }<br>
>> >> ><br>
>> >> > void thread2()<br>
>> >> > {<br>
>> >> >   while(1)<br>
>> >> >   {<br>
>> >> >     // n stores the slice start<br>
>> >> >     ready = false;<br>
>> >> >     while (!ready)                 // it gets a free slice<br>
>> >> >     {<br>
>> >> >       ready = true;<br>
>> >> >       for(i=n;i<n+slice;i++)<br>
>> >> >         if (buffer[i].st = -1)<br>
>> >> If you have this statement with an assignment operator, the<br>
>> >> while(!ready) loop should never terminate if slice > 0.<br>
>> >><br>
>> >> >           ready = false;<br>
>> >> >      }<br>
>> >> >     // process the slice on cluster<br>
>> >> >    pthread_mutex_lock(&mutex);<br>
>> >> >       for (i=n;i<n+slice;i++)<br>
>> >> >         buffer[i].st = -1;       // now new data can be inserted on it<br>
>> >> >    pthread_mutex_unlock(&mutex);<br>
>> >> >   }<br>
>> >> > }<br>
>> >> ><br>
>> >> > It runs fine on a Linux/GNU system, but not in RTEMS. Under some<br>
>> >> > circumstances the program is blocked. It is like if thread2 was running<br>
>> >> > forever on the second while, and thread1 didn't fill the buffer. Do you have<br>
>> >> > any idea of what is happening? I would expect that each thread would run on<br>
>> >> > parallel on each core.<br>
>> >> ><br>
>> >> > Thanks.<br>
>> >> ><br>
>> >> > _______________________________________________<br>
>> >> > users mailing list<br>
>> >> > users@rtems.org<br>
>> >> > http://lists.rtems.org/mailman/listinfo/users<br>
>> ><br>
>> ><br>
><br>
><br>
</p>