Pthread_mutex_lock

Per Oberg pero at wolfram.com
Fri Dec 4 17:06:34 CET 2020


----- Den 4 dec 2020, på kl 15:04, xenomai xenomai at xenomai.org skrev:

> Hi there Jan,
> Thank you for your fast response
> I am not too sure if i understood what you mean by compiling against
> Xenomai.
> Within my cmake I have attached the Xenomai's config, Posix Libraries and
> directories
> I have also added in a line to locate Xenomai's Pthread.h .

Hi

Sorry if I tell you things that you already know, but I thought that it would be better to start from the beginning. 

What you need to understand is that Xenomai comes with different skins, such as the posix skin or alchemy skin. The posix skin gives you the ability to use standard posix system calls and functions with pretty much the same functionality as regular posix functions, but with real time capabilities. 

One way of describing how this works is that the linker who puts together your compiled objects points all posix stuff to a xenomai wrapper. This wrapper then calls the correct functions for you. This means that it is not enough to include Pthread.h from Xenomai, you must also link with the right flags. 

There is a tool called xeno-config that will give you the compilation flags you need, e.g. 

xeno-config --cflags --skin=posix 
> -I/usr/include/xenomai/cobalt -I/usr/include/xenomai -O2 -pipe -g -feliminate-unused-debug-types -D_GNU_SOURCE -D_REENTRANT -fasynchronous-unwind-tables -D__COBALT__ -D__COBALT_WRAP__

xeno-config  --ldflags --skin=posix                     
> -Wl,--no-as-needed    /usr/lib/xenomai/bootstrap.o -Wl,--wrap=main -Wl,--dynamic-list=/usr/lib/dynlist.ld -L/usr/lib -lcobalt -lmodechk -lpthread -lrt -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed  


Note the bootstrap.o file which does some of the magic

I find that when compiling with cmake ( probably because I lack the expertise ) it quite easy to make it drop the flags by mistake. If you have made cmake aware of xenomai. Please check that the compilation flags are similar to mine, e.g. by using "VERBOSE=1 make" or something similar. If you have not made cmake aware of xenomai, then that is what is causing your problem. There are a few places where people have tried to make "find-xenomai.cmake" implementations that you could take advantage of but I am unsure of their status. 

That said, I use cmake and SOEM and it works fine for me. So it is possible.

Per Öberg 

> On Thu, Dec 3, 2020 at 8:31 PM Jan Kiszka <jan.kiszka at siemens.com> wrote:

> > On 03.12.20 17:39, John Ho via Xenomai wrote:
> > > Hi all, I wish to ask about this error I am getting from
> > > pthread_mutex_lock. I created a wrapper for SOEM and was trying to get
> > this
> > > wrapper to check on my ethercat slaves, however after running the
> > wrapper,
> > > I received an error stating :

> > > terminate called after throwing an instance of

> > 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error>
> > >> '
> > > what(): boost: mutex lock failed in pthread_mutex_lock: Operation not
> > > permitted

> > > After checking through what it was doing in GDB,

> > > #0 __GI_raise (sig=sig at entry=6) at
> > ../sysdeps/unix/sysv/linux/raise.c:51
> > > #1 0x00007ffff574d8b1 in __GI_abort () at abort.c:79
> > > #2 0x00007ffff6140957 in ?? () from
> > > /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> > > #3 0x00007ffff6146ae6 in ?? () from
> > > /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> > > #4 0x00007ffff6146b21 in std::terminate() () from
> > > /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> > > #5 0x00007ffff6146d54 in __cxa_throw () from
> > > /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> > > #6 0x00007ffff734e324 in void
> > > boost::throw_exception<boost::lock_error>(boost::lock_error const&)
> > > () from /home/john/Documents/SOEMWRAPPER/build/libsoem_wrapper.so
> > > #7 0x00007ffff734d093 in boost::mutex::lock() ()
> > > from /home/john/Documents/SOEMWRAPPER/build/libsoem_wrapper.so
> > > #8 0x00007ffff734e8c9 in boost::unique_lock<boost::mutex>::lock() ()
> > > from /home/john/Documents/SOEMWRAPPER/build/libsoem_wrapper.so
> > > #9 0x00007ffff734e6e1 in
> > > boost::unique_lock<boost::mutex>::unique_lock(boost::mutex&) ()
> > > from /home/john/Documents/SOEMWRAPPER/build/libsoem_wrapper.so
> > > #10 0x00007ffff735f474 in (anonymous
> > > namespace)::heartbeatMonitor(boost::mutex&, bool&) ()
> > > from /home/john/Documents/SOEMWRAPPER/build/libsoem_wrapper.so
> > > #11 0x00007ffff736287f in void
> > > boost::_bi::list2<boost::reference_wrapper<boost::mutex>,
> > > boost::reference_wrapper<bool> >::operator()<void (*)(boost::mutex&,
> > > bool&), boost::_bi::list0>(boost::_bi::type<void>, void
> > (*&)(boost::mutex&,
> > > bool&), boost::_bi::list0&, int) ()
> > > from /home/john/Documents/SOEMWRAPPER/build/libsoem_wrapper.so
> > > #12 0x00007ffff73627fe in boost::_bi::bind_t<void, void
> > (*)(boost::mutex&,
> > > bool&), boost::_bi::list2<boost::reference_wrapper<boost::mutex>,
> > > boost::reference_wrapper<bool> > >::operator()() ()
> > > from /home/john/Documents/SOEMWRAPPER/build/libsoem_wrapper.so
> > > #13 0x00007ffff73627b0 in
> > > boost::detail::thread_data<boost::_bi::bind_t<void, void
> > (*)(boost::mutex&,
> > > bool&), boost::_bi::list2<boost::reference_wrapper<boost::mutex>,
> > > boost::reference_wrapper<bool> > > >::run() () from
> > > /home/john/Documents/SOEMWRAPPER/build/libsoem_wrapper.so
> > > #14 0x00007ffff6eccbcd in ?? () from
> > > /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.65.1
> > > #15 0x00007ffff77936db in start_thread (arg=0x7ffff4f0b700) at
> > > pthread_create.c:463

> > > Is there a way for me to resolve this issue?


> > Is your wrapper compiled against Xenomai, redirecting pthread_mutex_lock
> > to the Xenomai implementation in libcobalt? Then EPERM from such a call
> > means that the caller is not a Xenomai thread, i.e. pthread_create was
> > called directly against libc, rather than being redirected to libcobalt.

> > Jan

> > --
> > Siemens AG, T RDA IOT
> > Corporate Competence Center Embedded Linux



More information about the Xenomai mailing list