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.
>
> PS: btw, the memory allocation mess is much worse than I suspected, and
> it is globally bad: this is not only a matter of properly sizing the
> private memory heap, but a general performance issues with all
> allocators, on different aspects and usage patterns. I'll follow up on
> this later this week with details.
Is that related to 8e606e681 or does it predate it / is orthogonal to it?
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
