Sebastian Huber wrote:
On 2013-08-07 08:18, Chris Johns wrote:
Sebastian Huber wrote:
On 2013-08-07 07:55, Sebastian Huber wrote:
On 2013-08-06 23:48, Chris Johns wrote:
Sebastian Huber wrote:
- (void) rtems_task_delete( RTEMS_SELF );
+ /* FIXME: Task deletion currently not supported */
+ (void) rtems_task_suspend( RTEMS_SELF );
In my view this is a blocker for 4.11. With such a bug we cannot say
SMP is
available and it was planned to be in 4.11.
Is there a "hold giant lock" level solution ? That is something,
even if
performance is poor, that is stable.
I don't know an easy solution for the thread deletion problem, see also
http://www.rtems.org/pipermail/rtems-devel/2013-July/003509.html
A list of other unsupported features can be found here:
http://git.rtems.org/rtems/tree/testsuites/smptests/smpunsupported01/init.c
The task variable API will never work on SMP
I consider this a feature. I never liked that API. This might break the
environment stuff related to the shell which I think uses it. I need
to check.
(the Ada self rtems_ada_self has the same problem).
I will leave that for Joel.
For Newlib a similar fixed with the usage of __getreent().
Do you mean newlib has this fixed with __getreent()
Sorry, I meant for Newlib a similar problem was fixed with the usage of
__getreent().
As a result the C++ support is currently broken on SMP.
Which specific bits ?
rtems_gxx_once() and the rtems_gxx_key*() stuff. This is used for global
and static C++ objects.
Yes this needs to be fixed. It is made more complex than just using
POSIX keys by the execute once function.
The non-preempt mode can work on SMP, but I think this would lead to a
broken design.
On SMP the Classic API should return an error.
The bdbuf and the once functions will not work due to that (mutual
exclusion via non-preempt doesn't work on SMP).
Yes, we need condition variables in the Classic API.
Yes.
We need to move the POSIX keys and condition variables to the score and
then reference the common code with each API.
Chris
_______________________________________________
rtems-devel mailing list
[email protected]
http://www.rtems.org/mailman/listinfo/rtems-devel
