> Ariane wrote:
>
> Could we add another argument to the rthread_attr struct?
> E.g. this would be specified together with the other rthread_attrs and
in the
> reconos_delegate_thread() function the thread would set its priority
> accordingly.
> This way we still can specify different priorities for different
delegate
> threads. The only restriction would be to set the priority of the
delegate
> thread higher than the priority of the other threads in the system.
Usually, the delegate thread *should* run with the priority specified
when creating the hardware thread. The eCos-like API takes the following
arguments:
void reconos_hwthread_create(
cyg_addrword_t sched_info,
rthread_attr_t * attr,
cyg_addrword_t init_data,
char* name,
void* stack_base,
cyg_ucount32 stack_size,
cyg_handle_t* handle,
cyg_thread* thread
);
Where "sched_info" is the priority and forwarded directly tot he
software delegate thread that is implicitly created. This seems to work
- the "mutex_test_ecos" test apparently runs just fine. The
POSIX-routines *should* behave in the same way; however, there the
priority is specified within the pthread_attr struct.
So I suggest that we look into these routines (namely 'rthread_create')
to see where things go wrong, instead of adding another rthread
attribute (which, in fact, would be a software attribute, anyway).
Also note that POSIX priorities are ordered in the opposite direction to
eCos priorities - with POSIX, higher numbers mean higher priority.
Best
- Enno
_______________________________________________
Reconos-devel_lists.reconos.de mailing list
reconos-devel@lists.reconos.de
https://ml01.ispgateway.de/mailman/listinfo/reconos-devel_lists.reconos.de
