Application based on Pthreads is blocked under RTEMS

[Joel Sherrill]

On Jul 4, 2014 9:19 AM, smc smc <smc101979 at gmail.com> wrote:
>
> 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.
>

With NULL as the attributes, they are different on the two systems.

Try to produce a small example which shows this behavior and the community can help.

>
>
> 2014-07-04 15:07 GMT+01:00 Joel Sherrill <Joel.Sherrill at oarcorp.com>:
>>
>>
>> On Jul 4, 2014 8:33 AM, smc smc <smc101979 at gmail.com> wrote:
>> >
>> > Hi, thanks all for your suggestions.
>> >
>> > @Sebastian: the bsp is MPPA.
>> > @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 '=='.
>>
>> You should be able to produce a generic version that bus smaller and reproduces the problem.
>>
>> 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.
>>
>> 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.
>>
>> > Anyway, I am trying to use condition variables, despite of loosing some of performance.
>> >
>> > Regards.
>> >
>> >
>> >
>> > 2014-07-03 2:37 GMT+01:00 Gedare Bloom <gedare at rtems.org>:
>> >>
>> >>  I'll make one note below, but you should submit the entire
>> >> self-contained example that shows the incorrect behavior if you want
>> >> debugging help.
>> >>
>> >> On Wed, Jul 2, 2014 at 6:23 AM, smc smc <smc101979 at gmail.com> wrote:
>> >> > Hi, I am new in RTEMS. I can't understand why the following threaded
>> >> > application is not running on RTEMS as expected. Basically, it creates two
>> >> > pthreads. One fills a buffer and the other one get an slice and submit it to
>> >> > a cluster for processing (typical producer-consumer problem), something
>> >> > like:
>> >> >
>> >> > void thread1()
>> >> > {
>> >> >   while(1)
>> >> >   {
>> >> >     for (i=0; i < size;i++)
>> >> >     {
>> >> >       if (buffer[i].st == -1)
>> >> >       {
>> >> >         pthread_mutex_lock(&mutex);
>> >> >           genData(buffer[i]);
>> >> >           buffer[i].st=0;            // ready to be consumed
>> >> >         pthread_mutex_unlock(&mutex);
>> >> >       }
>> >> >     }
>> >> >   }
>> >> > }
>> >> >
>> >> > void thread2()
>> >> > {
>> >> >   while(1)
>> >> >   {
>> >> >     // n stores the slice start
>> >> >     ready = false;
>> >> >     while (!ready)                 // it gets a free slice
>> >> >     {
>> >> >       ready = true;
>> >> >       for(i=n;i<n+slice;i++)
>> >> >         if (buffer[i].st = -1)
>> >> If you have this statement with an assignment operator, the
>> >> while(!ready) loop should never terminate if slice > 0.
>> >>
>> >> >           ready = false;
>> >> >      }
>> >> >     // process the slice on cluster
>> >> >    pthread_mutex_lock(&mutex);
>> >> >       for (i=n;i<n+slice;i++)
>> >> >         buffer[i].st = -1;       // now new data can be inserted on it
>> >> >    pthread_mutex_unlock(&mutex);
>> >> >   }
>> >> > }
>> >> >
>> >> > It runs fine on a Linux/GNU system, but not in RTEMS. Under some
>> >> > circumstances the program is blocked. It is like if thread2 was running
>> >> > forever on the second while, and thread1 didn't fill the buffer. Do you have
>> >> > any idea of what is happening? I would expect that each thread would run on
>> >> > parallel on each core.
>> >> >
>> >> > Thanks.
>> >> >
>> >> > _______________________________________________
>> >> > users mailing list
>> >> > users at rtems.org
>> >> > http://lists.rtems.org/mailman/listinfo/users
>> >
>> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20140704/3e5ac9ea/attachment-0002.html>