Change RTEMS GCC Thread model to POSIX.

[Chris Johns]

Joel Sherrill wrote:
> On 8/12/2013 8:41 AM, Gedare Bloom wrote:
>> Is anything lost by going to POSIX threads in GCC?
> Maintaining our own specific glue? :)

Yes. The threading support in gcc is designed around POSIX and when 
enabled gcc directly accesses the calls. No extra overhead calling an 
RTEMS wrapper. It also means we only need to make POSIX standard calls 
available now and into the future to be compatible. Any changes in gcc 
in this area will not break an assumptions we may have had.

All this excludes the fundamental issue that C++ is broken on SMP with 
the RTEMS thread model so it is not what is lost, it is what we gain, a 
working C++ compiler.

The classic API has no way to support the needed functionality in an SMP 
environment.

>
> Seriously, this will just mean you have to have POSIX enabled
> to have C++ run-time supported. This is the same as Ada now
> and some TCP/IP servers.
>

Correct and with the recent changes like the red/black key change the 
support is even better.

If you are running C++ on an SMP system enabling POSIX means little.

> Can this pthread view be applied to Objective-C?

It should. I have not confirmed this. The POSIX support layer in GCC 
handles objc. I will check later today.

> When I looked
> at it, I started down the path of using pthreads. Unfortunately, the
> code at that time had some non-portable stuff I ended up with
> RTEMS versions of that were "simple portable POSIX"

The only call I have removed is a yield and that is not needed on RTEMS.

>
> More on a broader matter below.
>
>> On Fri, Aug 9, 2013 at 3:06 AM, Chris Johns <chrisj at rtems.org> wrote:
>>> Hi,
>>>
>>> The patch attached changes the RTEMS thread model in GCC from 'rtems' to
>>> 'posix'. The patch also fixes the include paths for newlib so the
>>> correct
>>> 'machine/_types.h' is picked up.
>>>
>>> RTEMS using the POSIX thread model in gcc means C++ works with SMP. The
>>> 'rtems' thread model uses an RTEMS specific interface to code in
>>> RTEMS that
>>> uses task variables. Task variables make no sense and will never work
>>> in SMP
>>> systems [1].
>>>
>>> This patch leaves the RTEMS thread model in the gcc sources. A patch
>>> for gcc
>>> patches list would need to remove these sources.
>>>
>>> Chris
>>>
>>> [1] We should consider no building the task variable code when
>>> building an
>>> SMP kernel.
> The issues with disable preemption, task variables, disabling ISRs,
> etc when moving to SMP is going to be an issue for applications,
> add-on libraries, and language run-times.

Currently task variable add call returns an error when SMP is enabled. I 
have not checked what happens with the no-preempt mode change. That 
should also do the same.

I am wondering if an assert should be raised. These calls are dangerous 
and difficult to debug and if errors are not handled the user may not be 
aware a problem exists.

> Off the top of my head,
> I recall these are likely going to need work due to per task variables:

We also have no-preempt mode changes as well.

> + EPICS

Eric changed EPICS to use classic task notepads a while ago.

> + Ada run-time (Special Self in Thread Dispatch)
> + Go?
>
> We need to develop a collection of guidance. This is going to be
> a bumpy evolution for many code bases.

Internally we have privateenv, posix_once and bdbuf issues.

Chris