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.
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.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : [email protected]
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
[email protected]
http://www.rtems.org/mailman/listinfo/rtems-devel
