On Fri, Jun 18, 2010 at 7:42 PM, Gilles Chanteperdrix <
gilles.chanteperd...@xenomai.org> wrote:
> Nero Fernandez wrote:
> > Hi,
> >
> > Please find an archive attached, containing :
> > - a program for testing context-switch-latency using posix-APIs
> > for native linux kernel and xenomai-posix-skin (userspace).
> > - Makefile to build it using xenomai
>
> Your program is very long to tell fast. But it seems you are using the
> mutex as if they were recursive. Xenomai posix skin mutexes used to be
> recursive by default, but no longer are.
>
> Also note that your code does not check the return value of the posix
> skin services, which is a really bad idea.
>
> --
> Gilles.
>
Thanks for the prompt response.
Could you explain 'recursive usage of mutex' a little further?
Are the xenomai pthread-mutexes very different in behaviour than regular
posix mutexes?
The major portions of the code are the following three methods:
- main()
creates resource, spawns and collects pthreads
- rt_task_master()
calibrates the dry-run time, controls the mutex-passing and
reports the final timing. Measuring scheme is similar to lmbench
- rt_task_slave()
task for passing the mutex lock()-unlock() chain over.
The program allocates same number of mutexes as the number of processes,
so ideally only one thread would be active and each would its read and write
locks in the following fashion:
- unlock and lock , in case of master
- lock and unlock, in case of slave
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
