[rtems commit] smptests/smp07: Use suspend instead of delete
sebastian.huber at embedded-brains.de
Wed Aug 7 08:02:23 UTC 2013
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
>> A list of other unsupported features can be found here:
>> 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
>> 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.
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 : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the devel