I'm working on an AuxiliaryTask which should handle my OLEDScreen rendering at a way slower rate, and less critical, than my audio thread.

At some point I need to synchronize a bit of data (a pointer and a small struct) between the two, and I'm not sure which mutex library I should use.

AFAIK I should make sure in the end the implementation uses a Xenomai's rt_mutex, to avoid priority inversion.
Am I right ?

Also which way should I use it (if I do), since I'm not using the bela IDE but I'm cross compiling using VSCode ? Do I need to directly find a way to include the right Xenomai header ?
Maybe std::mutex already wraps a rt_mutex in this context ?

I grepped through the Bela code and couldn't find any occurence of rt_mutex

EDIT : If rt_mutex is the way to go it seems I found it in the alchemy headers, both on local host and remote target :
- host : /usr/local/linaro/BelaSysroot/usr/xenomai/include/alchemy/mutex.h
- target : /opt/xenomai-3/include/alchemy/mutex.h

    groumpf AFAIK I should make sure in the end the implementation uses a Xenomai's rt_mutex, to avoid priority inversion.
    Am I right ?

    that's documentation for Xenomai 2.6. We are using Xenomai 3.0 which has a pthread-like set of mutex functions. Here's the docs (very similar to the POSIX pthread_mutex docs): https://xenomai.org/documentation/xenomai-3.0.10/html/xeno3prm/groupcobaltapi__mutex.html
    Because of the Bela build settings, you should actually add __wrap_ before each function call, e.g.: turn pthread_mutex_init() into __wrap_pthread_mutex_init().

    groumpf Maybe std::mutex already wraps a rt_mutex in this context ?

    no. That's actually very hard to achieve as you'd need to build a customised version of the C++ standard library. The bets option for C++ use would be to use a customised XenomaiMutex class (e.g.: https://github.com/supercollider/supercollider/blob/develop/common/XenomaiLock.h). Keep in mind that in order for a thread to access a Xenomai mutex, it needs to be a Xenomai thread. An AuxiliaryTask already is a Xenomai thread, so this is not a problem, but if you want to use this class in a more general way (e.g.: from a std::thread), you need to account for the case where the calling thread is not a Xenomai thread, which leads to all this unelegant stuff in the implementation: https://github.com/supercollider/supercollider/blob/develop/common/XenomaiLock.cpp#L141

        OK thanks a lot 🙂 Nice to see they moved to a more POSIX-like API, I'm used to pthread so it's perfect.

        I'll indeed look first for a lock-free algorithm as much as I can, but I figured out it would be nice to know where to head if I truly new mutex at some point.

        3 months later

        groumpf You mention cross compiling using VSCode, can you please provide more details on how to do cross compiling using VSCode. I have searched the forum and can't seem to find a clear guide to follow.

            anubus Hi, I've setup it in different ways, with or without CMake, please tell me which one your are most interested into :

            • without CMake : easier to setup, uses the provided scripts for Bela, requires local linaro installation (for linting purpose), but does not compile on your machine, only on the bela board itself : slower and requires the Bela board to be plugged to compile code

            • with CMake & Linaro : a bit longer to setup, especially if you're not used to CMake build system. But once it's setup it has many features, better linting, cross-compiling (so way faster) and you no longer needs the Bela board to compile (usefull when travelling as an example).

            I could share both but it would take some time to setup in a public repository sorry

                groumpf Hi, with CMake please as I'm currently working on a different project that uses CMake to cross-compile code for the BBB. This will help me out a lot.
                thanks.

                  7 days later

                  groumpf Hi, just wandering if you have had the chance to share your vscode configuration?

                    Hi @anubus truly sorry for the time I take to answer. Yes I'll include my VSCode setup

                    I began working on the repository to share it with you, just cleaning a few things. I'll try to finish it today or tomorrow !

                    Here is a first draft, everything should be there but I didn't really took the time to test everything and to do some relectures : https://github.com/maxmarsc/xc-bela-cmake

                    I'll update stuff tomorrow, I'd like people to be able to use it easily so don't hesitate to test and to make feedbacks !

                      groumpf, many thanks for the time and effort you are putting in, it is much appreciated. Just had a quick look, looks pretty good, I will have a proper play with the setup over the weekend so I will keep you updated with any feedback. Thanks.

                      12 days later

                      groumpf I have manage to get enviroment setup fine. Thank you very much for the your time and effort. The only issue I'm having is with the debugger. While debugging, if I step into a Bela function such as scope.setup() I get

                      Program terminated with signal 
SIGSEGV, Segmentation fault.
The program no longer exists.

                      And I cant seem to to get it to use the local sysroot, meaning it loads the symbols from the BBB target.

                      7-interpreter-exec console "set sysroot /usr/local/linaro/BelaSysroot/"
Reading symbols from /home/e/bela_labs/xc-bela-cmake/build/bin/gdb_test...
Warning: 'set target-async', an alias for the command 'set mi-async', is deprecated.
Use 'set mi-async'.

Reading /lib/ld-linux-armhf.so.3 from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /lib/ld-linux-armhf.so.3 from remote target...

                      Have had this issue? any idea on how to resolve it?

                          anubus While debugging, if I step into a Bela function such as scope.setup() I get

                          If you run the program without stepping, does it segfault? Don't you get a "program received SIGSEGV" before those lines? That'd be the time to run backtrace and see what's happening.

                              giuliomoro running the program without stepping works, its only when I step into those functions I get SIGSEGV. I will try backtrace. What output do you get from the debug console when you start GDB? does it load all the lib Symbols?

                                giuliomoro from the GDB output the seg fault has to do with libc

                                
Thread 1 "gdb_test" received signal SIGSEGV, Segmentation fault.
0xb69cd72c in strnlen () from target:/lib/arm-linux-gnueabihf/libc.so.6

                                backtrace gives an error

                                -var-create: unable to create variable object

                                Now the seg fault happen when I get to this section in main.

                                // Initialise the PRU audio device
	if(Bela_initAudio(settings, 0) != 0) {
		Bela_InitSettings_free(settings);
		fprintf(stderr,"Error: unable to initialise audio\n");
		return 1;
	}

                                not sure how to debug this.

                                    anubus backtrace gives an error

                                    Is that all the text you get when you run backtrace?

                                    anubus when I get to this section in main.

                                    Bela_initAudio() in turn calls setup().

                                    If you see an error in strlen(), that's probably because or bad parameters being passed to something that in turn calls it. Does it show the values of the parameters it's been called with? Stepping from the beginning of setup() should pinpoint the issue.

                                        btw, I appreciate your insistence with remote debugging if that fits best with your workflow, but if you are actually interested in chasing down this specific bug, why don't you run gdb on the board instead? I have not had any of these issues when running locally before.

                                          giuliomoro that's a good point. I'm new to using GDB, so do you mean starting GDB locally with in the Bala terminal and entering debug commands from there?

                                            Yes, just log onto the board via ssh root@bela.local , cd to the folder containing the binary and do gdb BINARYNAME. If upon hitting a breakpoint or stopping you see a warning that the source file cannot be found, you can either simply cross-check any printed lines/filenames with the files that are on the host (good enough for short debugging sessions), or alternatively, use directory to point it to the source file(s).