[rtems commit] smptests/smp07: Use suspend instead of delete
Chris Johns
chrisj at rtems.org
Wed Aug 7 08:09:46 UTC 2013
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
More information about the devel
mailing list