On 04/19/2018 11:24 AM, Jan Kiszka wrote:
> On 2018-04-19 11:17, Philippe Gerum wrote:
>> On 04/17/2018 09:30 AM, Jan Kiszka wrote:
>>> On 2018-04-17 09:22, Philippe Gerum wrote:
>>>> On 04/13/2018 07:51 PM, Jan Kiszka wrote:
>>>>> None of the callers that run into the locks have RT requirements.
>>>>>
>>>>> Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
>>>>> ---
>>>>>
>>>>> As noted before, I think we should even be fine with STD locks, but that
>>>>> may require more changes.
>>>>>
>>>>> lib/copperplate/registry.c | 2 --
>>>>> 1 file changed, 2 deletions(-)
>>>>>
>>>>> diff --git a/lib/copperplate/registry.c b/lib/copperplate/registry.c
>>>>> index daefa6c97..1bf0ebfea 100644
>>>>> --- a/lib/copperplate/registry.c
>>>>> +++ b/lib/copperplate/registry.c
>>>>> @@ -175,7 +175,6 @@ int registry_init_file(struct fsobj *fsobj,
>>>>>
>>>>> pthread_mutexattr_init(&mattr);
>>>>> pthread_mutexattr_settype(&mattr, mutex_type_attribute);
>>>>> - pthread_mutexattr_setprotocol(&mattr, PTHREAD_PRIO_INHERIT);
>>>>> pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_PRIVATE);
>>>>> ret = __bt(-__RT(pthread_mutex_init(&fsobj->lock, &mattr)));
>>>>> pthread_mutexattr_destroy(&mattr);
>>>>> @@ -758,7 +757,6 @@ int __registry_pkg_init(const char *arg0, char
>>>>> *mountpt, int flags)
>>>>>
>>>>> pthread_mutexattr_init(&mattr);
>>>>> pthread_mutexattr_settype(&mattr, mutex_type_attribute);
>>>>> - pthread_mutexattr_setprotocol(&mattr, PTHREAD_PRIO_INHERIT);
>>>>> pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_PRIVATE);
>>>>> ret = __bt(-__RT(pthread_mutex_init(&p->lock, &mattr)));
>>>>> pthread_mutexattr_destroy(&mattr);
>>>>>
>>>>
>>>> This one raises an interesting issue: since commit #8e606e681,
>>>> registry_{add, destroy}_file() use plain malloc(), therefore are subject
>>>> to mode switches, dropping the real-time guarantee from object
>>>> creation/deletion routines such as rt_*_{create, delete}() calls from
>>>> the Alchemy API.
>>>>
>>>> Previously to such change, some of these routines did not provide such
>>>> guarantee anyway, e.g. rt_task_create(), but others did like
>>>> rt_mutex_create(), rt_cond_create().
>>>>
>>>> I'm now questioning those specific changes in registry_{add,
>>>> destroy}_file(), because they might break applications assuming that rt
>>>> mode is not lost when calling them, which is still true if the registry
>>>> is disabled, leading to a fairly confusing inconsistency.
>>>>
>>>> Merging your patch would enforce this change in behavior even more,
>>>> carving in stone that all object creation and deletion routines which
>>>> interface with the registry won't be rt-capable anymore.
>>>
>>> Sure, we need to sort out the rt_*_create topic prior to being able to
>>> decide about this one.
>>>
>>>>
>>>> Would that be generally acceptable?
>>>
>>> I would not expect a lot use cases to be affected by that. The bare
>>> minimum would be documenting this in the 2->3 migration guide.
>>>
>>> OTOH, given that this is the stable series, such a change (8e606e681)
>>> may better wait for 3.1.
>>>
>>
>> This change should be reverted. The more I think of it, the more I see
>> no reason to restrict object creation/deletion to secondary mode if the
>> actual implementation does not require this.
>>
>
> Over the time, we consistently moved more and more parts away from
> RT-capable object creation/destruction, though.
>
Driver-wise sure, not in the non-POSIX APIs where traditional RTOS don't
usually enforce such restriction, and copperplate is there to support
those APIs specifically. If this is about preventing regressions, then
introducing this restriction in existing apps - which assumed no latency
issue would exist with creating (lightweight) objects on the fly - could
be a problem. That is what should wait for 3.1, with proper
documentation of the change in behavior.
Only registry_add_file() and registry_destroy_file() would need to be
switched to xn* calls in 3.0.x to fix the original issue, and prevent
regression. The rest lives on top of the fuse fs server thread and is
fine with plain malloc.
--
Philippe.
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
